Articles on business analysis
These articles will consider business analysis practice, approaches, techniques, management and tools as well as a look at current concerns and future trends for business analysis.
Levels of business analysis
- Strategic: Business transformations; Portfolio management; Business change; Business architecture and Target operating models; Business agility; Benefits realisation.
- Operational: Business processes; Business data; Management information and Decision support; Business rules; Business cases; Business requirements discovery; Problem analysis.
- Tactical: Software requirements specification and management;
Business Analysis Roles and Qualities
Business analysis is a demanding function comprising many specific roles, e.g.
– Agent of change; Problem Solver; Modeller; Planner; Facilitator; Negotiator; Reporter; Mediator; Interpreter; Fact Finder; Interviewer; Reviewer; …
Business analysts need to be:
– Business and people oriented; Technically savvy; Effective networkers; Team players; Independent of politics; Self starters; …
Business Analyst Skills Profile
To fulfill the demands of the job, business analysts need a variety of skills, both hard and soft, e.g.
- Understand the nature of business strategy, goal setting and business planning.
- Able to think conceptually, to analyse and understand root causes of problems and to identify business based solutions to the identified problems.
- Able to create business architectures and participate effectively in business change programmes.
- Competent with business process modelling, business data modelling and business rules.
- Requirements discovery and specification techniques for functional and non functional requirements.
- Possess a large range of communication skills including making presentations, interviewing, facilitation of workshops, attending and running meetings and report writing.
- Demonstrate inter-personal skills such as team leading and negotiation.
- Apply project skills such as the creation of business cases, setting objectives, planning, estimating and project management.
Optimising Business Analyst Performance
A business analyst’s role is very much about the continuous improvement of business capabilities. But the capabilities of each business analyst and the whole business analysis function also need to be continuously improved .
Unfortunately, business analysts and other team members often do not have the time, the independence, the authority or appropriate organisational structures to examine and improve their own capabilities and to optimise their own processes and performance.
Sometimes business analysis teams are not aware what a process of continuous improvement of their own capabilities might look like. Agile business analysis approaches can help, but even here it is not always easy to agree what should be done, how to go about doing it or finding the time to do it. This is where the Business Analysis Centre of Excellence (BACoE) comes in.
A Business Analysis Centre of Excellence (BACoE) (or Center of Excellence in the States), is a framework that provides structure, context and content for improvement initiatives in business analysis and its relationship to other development centres.
Why have a business analysis centre of excellence?
Business analysis skills, and suitably skilled business analysts, are critical to the success of change projects, particularly when it comes to:
- Discovering the essence of the business problems to be solved and the business opportunities to be achieved
- Solving those problems in a manner that is line with the business and IS/IT strategic objectives
- Identifying and managing risks and benefits of the proposed solution in line with corporate and IT governance policies
- Achieving business agility – the ability to respond rapidly and effectively to a changing world
The business analysis team obviously cannot achieve the above alone. A framework for cooperation, communication and negotiation with all business and IT stakeholders is critical to project success. This framework is supplied by a business analysis centre of excellence.
So what is a business analysis centre of excellence?
As we have already stated, a Business Analysis Centre of Excellence is a framework that provides structure, context and content for improvement initiatives in business analysis and its relationship to other development centres. A business analysis centre of excellence can tackle everything highlighted in the above paragraphs.
Why terms of reference?
Terms of reference are a key tool of business analysis. They are a vital control for:
- activities and work packages within the project
- project governance and management
- project team members
A useful mnemonic for possible elements of a terms of reference is BOSCARD. It provides a framework for a terms of reference and is the basis of a contract between the business analyst and other project team stakeholders.
BOSCARD stands for:
- Background: What is the background to this project? What is the problem to be solved or the opportunities to be realised? The business analyst is directly concerned with identifying the business problems and opportunities
- Objectives: What are the objectives for this project and for the product or service that it will create? Objectives should relate to the statements in the ‘Background’ about problems and opportunities. Try to relate the project and product objectives to the higher level corporate objectives that this project will support through the provision of its products and services. Objectives can also be linked to the anticipated benefits that this project will realise.
- Scope: Define what is IN and what is OUT of scope for the project or project activity. Scope can be represented graphically by using a context diagram: see below.
- Constraints: Identify constraints such as time and money applicable to the project or project activity. Constraints may also define the format and standards applicable to the deliverables; e.g. ‘Apply in house standards when creating user stories’.
- Authority: Identify the hierarchies of authority that govern the project or project activity.
- Resources: Identify the people with a role within that project. For business analysis related activities, identify the people and the roles that will work with the business analyst. Also identify any non human resources that will be required, e.g. development tools, rooms, equipment, software licences, etc.
- Deliverables: What the project or project activity is supposed to create. The business analyst is typically responsible for delivering the requirements. Other business analysis deliverables include problem analyses, analyses of business processes, business information (data and concepts), business rules, benefits, costs and risks
There is a natural partnership between the project manager and business analyst. The BOSCARD represents a form of contract between the project manager, the business analyst and other players in the project or project activity.
Context diagrams are a great way of demonstrating, discussing, agreeing and reviewing the scope as defined in the terms of reference. Context diagrams may be used show any of the following:
- Scope of a project
- Scope of (sub) activities within the project
- Scope of a role or a project team member
The square at the centre of the context diagram can represent any of the following:
- Organisation or organisation unit
- The product or service that the project intends to create
- A project
- A project activity within an overall project
- A project role or project member; this can show communication channels to and from other roles
The smaller squares surrounding the central one are referred to as ‘externals’ or ‘external entities’. They represent bodies that the central unit communicates with. What they are in any particular case will therefore depend on what the central unit is supposed to represent, e.g. organisation, product, project or team member. In these different cases, the externals could be:
- External organisations such as customer and suppliers
- Internal organisation units which will have to communicate with the project team
- Computer systems which the product to be delivered will have to interface (inter-operate)
- Work units that the concerned role or team member must communicate with
Who Writes the TOR?
The terms of reference are normally created by relevant sections of the project team.
For business analysis activities, the team may include:
- Project sponsor
- Business analyst(s)
- Product manager / owner
- Representatives of the concerned business areas
- Representatives of the architecture, design, development, implementation, test and release management teams
- Project manager
- Representatives of the externals
Terms of reference for a role or an individual may be written members of the role or by the individual concerned.
Agreeing the TOR
Terms of reference must be agreed by all concerned parties.
As requirements are discovered (elicited) and captured, they should periodically be analysed; they can be analysed for completeness, correctness, priority, release date, ambiguity, clarity, testability, achievability, cost, risk, scope, cultural feasibility, etc. This is true whether the requirements are captured as user stories, use cases, business tasks or any other format.
The requirements analysis process involves checking backwards with the requirements owners (e.g. product owner(s)) and forwards with the stakeholders who will use the requirements in some way, e.g. to design, build. test, release or administrate the required system.
In checking back (requirements validation) with the owners of the requirements, we are trying to ensure that the real business needs have correctly identified and defined. Consider the goals of the project as well as the overall goals of the organisation, the business case, the priorities and the scope for the project; does the requirement respect these? Have the goals or the scope changed, perhaps with a change of sponsor for example? Do the requirements seem to be related to the original problem? Do we remember what that problem was? Have we identified and involved all of people and groups affected by the requirements?
In these reviews with business stakeholders, ensure that they really do understand the requirements as written. Is this what they wanted? The big question to ask is, ‘How will the requirements, as written, contribute to the solution of the original problem?’ This is the rationale for the requirement; it can sometimes be very difficult to get the stakeholders to clearly specify a rationale. If there is no rationale, the requirement needs to be dropped.
In reviewing the requirements with the people who will build or otherwise acquire as system that satisfies the requirements, we need to ensure that a system as represented by the requested requirements can be built and tested within the defined constraints. In the context of testing, and of development, we need to ensure that there are clear and unambiguous acceptance criteria. The obvious way of doing this is to have the requirements reviewed by the people who will be doing the building and testing; the architects, designers, programmers, testers and release managers.
A well constructed requirement should normally permit multiple solutions. Is this true of the requirements at hand or are they actually solution statements masquerading as requirements? If they are solutions, is this ok? Usually it is not.
That said, we also need to ensure that the required product can be developed within the constraints imposed by the business. Realistic costs can only be determined in the context of the design options, or potential architectures.
Assessment of requirements must therefore involve people with sufficient technical skills and experience to understand the likely implementation costs. If the organisation cannot afford the solution, or cannot justify that expense in terms of benefits, it is not worth continuing with the development.
If what is being requested is not feasible for any reason, e.g. technical complexity or cost, the designers and architects may be able to come to the rescue with an application of the 80:20 rule; e.g. make some changes to the requirements to be able to get most of what you want with less risk and cost.
Requirements reviews, as described here, should be done as early as possible. The earlier in the life cycle the problems are discovered, the quicker and easier it will be to resolve them. This increases the chances of achieving a workable solution first time. Obviously, just because it’s workable does not mean that it really will solve the business problem or will realise the opportunity; in the end, we just have to get it out there and see. This a justification for agile style developments with ‘minimum viable products’ and ‘failing fast’.
Analysis with Models
There are risks in relying purely on text to define requirements. Ambiguity is a problem. It can be difficult to assess completeness. One solution, or partial solution, to do these problems is to use models.
There are mixed opinions about the value of models, particularly formal models. One option is to use informal models, sometimes referred to as napkin models. These are easier for business stakeholders to create and can be less intimidating. Formal models however have more rigour; they are essential when we are intending to automatically generate applications and databases from models. Popular forms for formal models include UML and BPMN.
For Complex systems (with the capital ‘C’), there are other considerations in terms of value of models, but such highly specialist considerations are beyond the scope of this article.
Analysis and Prototyping
Another way of mitigating risks inherent in requirements defined as text is prototyping. Prototyping is popular but there are consequent risks such as the popularly quoted management of user expectations. Another risk is that we may suddenly find that we are no longer dealing with requirements but with solutions; as stated above, a well formed requirement should allow for multiple solutions.
When we are eliciting requirements, the prototype should be as minimalist as possible; the prototype should be used to encourage discussion about the real need.
When we are validating requirements, prior to purchasing a solution or starting system development, the prototype should be detailed enough to show what the system will look like. This gives stakeholders a chance to say, “Now that I’ve seen it, I realise that it’s not what I want.
Our analysis, including reviews, modelling and prototyping, should clarify everyone’s ideas and should give us confidence that we are on track to create what is really needed to solve the business problem or realise the business opportunity. Such clarity facilitates estimating the workload ahead and helps to set expectations and share a vision. All of this will be good news to the project manager and senior management.
Chinese Whispers in requirements discovery
The child’s game, referred to in English as Chinese Whispers, is one in which children, typically seated in a circle, receive a whispered message from the person on one side and whisper it to the person on their other side. The last person in the circle has to say out loud what they they heard.
To the delight of the children, this usually has nothing to do with the original message. Unfortunately the process of requirements discovery also displays some of the characteristics of the child’s game. The more links in chain, the more likely that there is miscommunication.
Business analyst – Problem or Solution?
Perhaps the easiest way of solving this problem is for the person with the requirements to talk directly to the person who will provide a solution. This minimises the number of people in the chain and consequently the possibilities for misunderstanding. Some ‘agile’ projects work this way, often with great success. Sometimes with not such great success.
The job of the business analyst is to listen to the person with the requirements and to pass on these requirements to the people who will participate and cooperate in the provision of a solution. So what value add does the business analyst offer?
If the business analyst is simply acting as a relay, the answer to this question is, ‘very little – if anything’. In fact, if the person with the need is capable of clearly defining the problem to be solved and the requirements that any solution must satisfy, the business analyst would be redundant.
What can the business analyst bring to the party?
The value of the business analyst rests on their capability to deal with issues such as the following:
- the problem is often not well understood or well defined
- the solution attacks a symptom rather than an underlying problem
- the requirements are not well expressed
- there are usually many people with specific, perhaps personal, goals and requirements
- the budget may not be sufficient to satisfy all the requirements
- requirements, and even goals, may be mutually conflicting
- suggested solutions may not be culturally feasible
- the implemented requirement improves one bit of a process but worsens the overall outcome
- the requirement satisfies a group of stakeholders, but not all of them
- continuous reinvention of the wheel
and so on.
To be of value, the business analyst needs to do much more than simply pass on a message.
Business analysts analyse business problems
The business analyst (BA) must get to the root of a problem or the essence of an opportunity. They must frame requirements without unilaterally imposing an arbitrary solution. They usually need to assist concerned parties in creating a common understanding of the business problem or opportunity that is being targeted by the project. They often need to negotiate with with the business and with IT in order to identify an approach to a solution that recognises constraints, priorities, benefits and risks.
Is this you?
If yes, you’re not alone. I’ve met many business analysts struggling to specify business rules and multiple conditions using techniques such as user stories or traditional requirements formats. And they end up in a tangle.
When I demonstrate decision tables, it’s like an epiphany. I’ve even had analysts ask if they’re allowed to use the technique – “Shouldn’t we be using user stories”?
Decision tables are a great technique for business analysts, business architects, developers, and testers alike. They are equally applicable to agile and to traditional teams. And the good news is, they’re simple to learn.
There are two forms of decision table. In this article we’ll look at the most basic form, known as ‘limited entry’.
We start with the conditions.
Start with an IF
Conditions are the ‘IFs’ and possibly the ‘WHENs’. E.g.,
- IF order value greater than £500.00
- IF client is loyalty scheme member
However, in decision tables we do not include the IF word. For example, we could simply write:
- Order value greater than £500.00
- Client is loyalty scheme member
Imagine a question mark at the end of each of the above statements, e.g. Order value greater than £500.00?
This is either TRUE or FALSE. Some decision table users refer to YES and NO. The more mathematically minded might even use the numbers ‘1’ and ‘0’ instead of true or false, yes or no.
Brainstorm or workshop all the conditions that you can think of. One of the great things with decision tables is that you can write them down in any order.
Decision tables can handle any number of conditions but to explain the technique we’ll start with a very simple situation with only two conditions.
The situation is a hotel check-in. Possible conditions might be:
- Does the client have a booking?
- Is there a room available?
The column of conditions is known as the ‘condition stub’
True or false?
Each condition is either true or false, e.g. the guest either has a booking or they don’t. A typical beginner’s mistake is to add additional conditions such as, ‘Guest does not have a booking’; this is unnecessary.
In the diagram labelled ‘Simple Conditions’, we have represented ‘True’ with a ‘Y’ for YES. We have represented ‘False’ with an ‘N’ for ‘No’.
Combinations of conditions – Rules
You can see that with two conditions there are 4 possible combinations of true and false. A great thing about decision tables is that we can be absolutely certain that we have identified all combinations of conditions; we have missed nothing.
If there are 3 conditions, there are 8 combinations of true and false.
For 4 conditions there are 16 combinations of true and false.
You can probably see that the number of combinations rises steeply with each extra condition. But however large the number combinations becomes, we can be absolutely certain that we have identified all of them; we will have missed nothing. That should be reassuring to business analysts, solutions architects, programmers, testers, project managers and business stakeholders.
The good news is that there are a couple of techniques we can apply to simplify complex tables. These are known as:
We shall examine these later.
We have labelled each combination of conditions as a ‘Rule’; i.e. Rule 1, Rule 2, Rule 3 and Rule 4. In the language of decision tables, these are collectively known as the ‘condition entries’.
Having identified the conditions, we can identify actions. Note that we could have identified the actions before we identified each of the combinations of conditions, i.e. the rules. Decision tables allow us great flexibility in the order with which we do things.
In our example, we have identified four actions:
- Check in guest
- Create booking
- Find room in another hotel
- Recompense guest
This set is referred to as the ‘action stub’.
In our decision table, we have listed the actions below the conditions. We have separated conditions and actions with a thick blue line.
We could have listed the actions in any order we like. There is no limit to the number of actions we can identify.
Associating Rules and Actions
For each combination of conditions, i.e. for each rule, we examine each action in turn.
For each rule, we determine whether or not an action is applicable. We do this by putting an X where it is applicable and a dash (–) where it’s not.
If the action is applicable for a particular rule, put an ‘X’ in the cell for that action in the column for that rule. E.g.
- If a guest has a booking
- If a room is available
- Check in guest.
In the diagram, ‘Condition and Action Stubs + Condition Entries‘, notice the ‘X’ in:
- Row: ‘Check in guest’
- Column: Rule 1
If the action is not applicable, either:
- Put a dash, ‘-‘, in the cell
- Leave cell empty
For example, notice in the diagram that there is a ‘-‘ in the column, ‘Rule 1’, for each of the the following action rows,
- Create booking
- Find room in another hotel
- Recompense guest
I.E., none of these 3 actions is applicable if the guest has a booking and a room is available.
More complex decision tables
The example, ‘Incomplete decision table with 3 conditions’, shows all the combinations of true and false, or yes and no, when there are three conditions.
We can see that in this case there 8 possible combinations of true and false (yes and no), denoted by rules 1 – 8.
The decision table format gives us confidence that there are no more possibilities. We have not missed anything.
We can similarly handle 4 or more conditions. Each time we will know that we have identified all possible combinations.
However, it’s always a good idea to try to simplify things a bit.
Simplifying complex decision tables
If there are many conditions, a decision table can become very large. Fortunately we can usually manage to simplify such tables by using ‘indifference’ and ‘else’
Simplifying by using the ‘Indifference’ symbol
The indifference symbol is a ‘-‘ (i.e. a dash or a hyphen).
The example shown in the adjacent diagram, ‘Partial decision table showing indifference’, is based on a scenario such as purchasing a train ticket online.
Before the payment can be processed, it is often necessary to accept the terms and conditions (T&Cs). This is usually done by clicking in a checkbox.
If the user had not indicated acceptance of the T&Cs, the payment cannot be processed. Typically the system displays a message telling the user that they must accept.
In our diagram, there is an ‘N’ in Rule 1 of the ‘Terms and conditions agreed’ row.
The ‘N’ tells us that the T&Cs have not been accepted. In that case, it does not matter what is in the other conditions for Rule 1. The resultant action will always be the same. If T&Cs have not been agree, we are not going any further.
The action is ‘Display “T&Cs must be agreed” ‘. In the diagram there is an X in the row for that action.
There are likely to be similar conditions, e.g.
- Card payment details incorrect
- Post code missing
Items such as the above are mandatory for payment processing to proceed.
Simplifying with Else
Having dealt with cases such as mandatory items being completed, we often find that all other rules result in the same action or actions. This allows us to replace all of those rules (columns) with a single column labelled ELSE. See the adjacent diagram, ‘Partial decision table showing use of ELSE’.
Notice that all the cells in the ELSE column are blank. ELSE represents all situations other than the three covered by rules 1, 2 and 3.
The table shows us that for all situations other than for rules 1, 2 and 3, the resultant actions are:
- Action 2
- Action 3
Not every requirement is best specified with a user story or a use case or with traditional formats such as, “The user shall …..”.
Decision tables are a useful technique for business analysts when specifying applications and systems that involve multiple conditions and business rules.
They are also useful for programming, design, testing and management.
Try adding them to your toolbox of business analysis techniques.
There is no universally agreed, ‘standard’ definition of the term requirement; many groups and individuals will have their own definitions. In general, it is reasonable to assume that a requirement represents something of value to the person or group that expressed it.
IEEE (Institute of Electrical and Electronic Engineers) offers the following definition:
- A condition or capability –
- needed by a user to solve a problem or achieve an objective –
- that must be met by a system or system component to satisfy a contract, standard, specification or other formerly imposed document.
There are plenty of other definitions. What we like about the IEEE one is the emphasis on solving a problem and realising an objective. A feature of Capiro’s mission is to help clients to identify the problems, objectives or opportunities before attempting to acquire a solution.
So, in looking for requirements, we could start by identifying the problems that are blocking the achievement of objectives or the realisation of opportunities. An immediate question is, whose problem, whose opportunities and whose objectives? Success with requirements demands that these people, all of them, be identified and engaged with; they must be listened to.
To achieve this aim, it is essential to work with the people most concerned with solving the problem or realising the opportunity; these are the stakeholders. The concept of a stakeholders may also covered by terms such as product manager, product owner, user or actor. Related concepts, terms and roles include change manager, benefits owner, subject matter expert, product champion or evangelist. I have also heard them described as the performers.
A challenge for anyone seeking to understand people’s requirements is that these stakeholders are not a homogeneous group. They are individuals and groups of individuals with individual (or group) perspectives, cultures, ambitions, needs and agendas. They do not all share the same idea of value. Putting all of this together frequently results, to a greater or lesser extent, in conflict. The ‘requirements seeker’, e.g. the business analyst or product owner, needs to be a great facilitator and negotiator.
The potential for confusion is increased with the proliferation of terms such as business requirement, user requirement, software requirement, feature, and so on. These terms are often used interchangeably, even within the same organisation. It is usually a safe bet that the organisation does not have an agreed set of definitions for these terms. Creating a restricted set of preferred terms and definitions would be a great start to improving your requirements process.
Another challenge for the requirements seeker is that requirements are not always expressed concisely, clearly or completely. There is a concept sometimes referred to as ‘customer expectations’. Customer expectations can extend well beyond the expressed requirements. They can be tacit or explicit, realistic or fanciful, creative or mundane. In order to really delight your customers you need to coax these expectations into the light. You then need to really understand them. With the help of other team members, you need to understand if it is feasible to realise them, financially, technically and culturally. And if they are are feasible, are they desirable?
A complete requirements process is likely to include at least the following activities:
- Requirements elicitation
- Requirements analysis, perhaps with requirements modelling
- Requirements recording (documentation)
- Requirements management
There are of course various approaches, techniques and tools that can be used to realise the process. We shall cover these in future posts.
To support business analysis training, the BCS offer a range of examinations. One group of these are aimed at the BCS International Diploma in Business Analysis.
To obtain the diploma it is necessary to pass four written exams followed by one oral examination.
Two of the exams are mandatory (core): Business Analysis Practice and Requirements Engineering.
You may select your other two exams from two streams. You must pick one exam from each of the two streams. The streams are named, ‘Knowledge Based’ and ‘Practitioner’ respectively.
The BCS themselves do not offer training for the exams but instead accredit training providers. There are a number of options for a candidate to take an exam. Not all options are available for all exams.
There are two formats for the BCS exams.
Format 1. Open book, scenario based.
Format 2. Closed book, multi-choice.
Format 1 exams are written and marked by accredited providers.
Format 2 exams are in effect written and marked by the BCS. These are referred to as ‘central’ exams. They may be taken with a provider, or online, with Pearson VUE.
Format 1 is the norm for the mandatory exams and for the practitioner stream.
Format 2 is the norm for the knowledge based stream.
The BCS is planning more central, multi-choice, exams, but the dates for publication are yet to be confirmed.
Options for taking written exams
- With a provider, typically at the end of a training course given by that provider.
- With a provider without having taken a course; this is referred to as the exam only option. Not all providers offer this option.
- Online with Person VUE. This option applies only to the multi-choice exams. The BCS have said that they will multi-choice exams for more of their courses but no dates are currently showing on their web site.
Exams are also offered a few times a year at the BCS centres in London or Edinburgh. Check the BCS web site for details or contact the BCS and ask when places for the exam that you interested in will be offered.
Options for taking the Oral Exam
There is only one oral exam and it can only be taken with a BCS examiner. There are several approaches taking the exam, e.g.
- At a BCS centre, i.e. Southampton Street, London and St. Mary’s Street, Edinburgh.
- Have a BCS examiner visit your organisation. BCS can tell you how many oral exams they can run in one day. You will be liable for the examiner’s expenses. This is of interest to organisations rather than individuals.
- Remotely, i.e. online to a BCS examiner.
Do check conditions and costs directly with the BCS.
BCS examiners are not employees of BCS.
Note that the oral exam has its own syllabus. This is available on the BCS web site.
The Written Examinations
There are currently 10 examinations that are eligible for the Diploma. These are grouped in three categories:
- Knowledge Based Specialism: essentially these are the courses that BCS also offers under its Foundation scheme.
- Practitioner Specialism: essentially these are the courses that BCS also offers under its Practitioner scheme.
Let’s examine these group by group
Core (Scenario based open book exam)
- Business analysis practice.
- Requirements engineering.
The 2 core courses also form part of the ‘Practitioner’ series.
Knowledge based specialism (Multi-choice closed book exam)
- Foundation certificate in business analysis.
- Foundation certificate in business change.
- Commercial awareness.
- Foundation certificate in project management.
Practitioner based specialism (Scenario based open book exam)
- Modelling business processes
- System modelling techniques
- Benefits management and business acceptance
- System development essentials
Applying to take the oral examination
Through your exam provider
If you take a training course with an accredited provider, they can get you booked for an oral examination.
See the BCS web site for the following:
How to really succeed with anything
Start with one normal guy
The title of this article is taken from the title of a book by Ben Hunt-Davis and Harriet Beverige which describes “Olympic winning strategies for everyday success”. At the start of the book we read, “Ben Hunt Davis is a normal guy. He is also a Olympic gold medallist. How did he succeed?”
Build a team
The philosophy, approach and practices described have a lot of relevance to the work of the business analyst; they have considerable relevance to the analyst trying to work in a more agile fashion.
The book is about :
- a team and the individuals that comprise that team
- the concern and sense of responsibility for their own outstanding performance and for the overall outstanding performance of the team
- It is about a winning team
- It is also dedicated to the team’s coach
The book is fairly short and well worth reading. In fact, why not get a copy for every member of your team ?
Learn to pivot
A consistent theme of the book concerns asking, for everything that the team do, “Will it make the boat go faster ?”
In other words, will it help us to achieve what we want to achieve ?
If not, change that thing – or jettison it.
And this really must be applied to everything :
- Your goals
- The process you follow
- The variables of that process
- Relationships with colleagues and others
Winners make goals and goals make winners
At the start of the book, Ben points out the importance to his rowing team of being really clear on what they wanted to achieve. He likens goals to magnets – magnets that pull you forward. Studies have shown that people who set goals are more likely to achieve what they want.
In the team setting, identifying goals makes it clear where the team is heading. It also makes clear if there are conflicts between the goals of individual team members. The team needs to know that everyone shares the same vision at the outset, even if that team vision changes in the light of experience.
Ben stresses the importance of making everything open and transparent. This is achieved to a large extent with continual team discussions and reviews. Every goal must be individually important to each team member, perhaps for different reasons in each case. It’s about asking, “What’s in it for me?” and liking the answer. And every team member should understand how the goal will make the boat go faster ; “What’s in it for the team ?”
Extreme goal setting
Ben recommends setting a hierarchy of goals, starting with the “crazy goals”.
Crazy goals are those great ambitions that you might never achieve but which nevertheless provide you with a stimulating vision and a basis for creating a road map to get to where you want to be. Crazy goals are the big things. They are exciting and perhaps a bit daunting. Achieving them probably forces us out of our comfort zones. They are what leads certain teams to excel.
On the negative side, they might also be those things that make us doubt our competence when the road seems long and the going gets tough.
For high performing teams, crazy goals are more than a dream. They are not the equivalent of Harry Potter gazing into the Mirror of Erised and dreaming about things without taking action – those sort of dreams will never be achieved.
Realism and focus
How do you measure up ?
Below the crazy goals we have concrete “measurable goals”.
If you can’t measure them, how will you know if and when you have achieved them ? Ben says that this is like running in a race with no finishing line.
I once worked on a project where I headed up the IT group. The overall project was led by a senior marketing manager. When I asked about the goals for the project, I was treated to a withering look and the response “We will know when we get there”. In other words, “I’ve got no idea what the goals are – I’ve got no idea why we are doing this project or why the bank is funding it”; not a great start for benefits management and realisation.
Know your limits
Ben also distinguishes between those goals that are within your control to achieve and those goals that are outside your control ; this is a critically important distinction if you are to avoid frustration.
For those goals that are outside your control, it may be worth determining whose control they fall under ; perhaps a business analyst can use their influencing skills to achieve change.
Start at the bottom
Finally, Ben suggests that we should have “every day goals”; these provide the detailed, measurable, steps for getting to where we want to be. They are at the bottom of the hierarchy but without them you’re going nowhere.
Know why and know how
As well as understanding the value of setting goals, the effective business analyst will know how to identify and formulate goals ; this may involve using one of the many techniques that exist for modelling goals.
It is always worth while challenging your own goals. Consider them and ask yourself, “Is this really and truly what I and the team want or need to achieve ?”
Having set their goals, the Olympic rowing team determined strategies for achieving them.
In the rowing team’s case, the strategies included belief in oneself and the team and developing a can-do attitude.
The set of strategies also included, ‘making the journey enjoyable’ ; this is typically a valuable feature of agile approaches.
Ben also points out that you need to know the difference between when it’s time to relax and when it’s time to really focus and get the job done.
Other strategies concerned :
- Creating milestones and rewarding yourself when you achieve them
- Making yourself hungry for success
- Doing things in short bursts or ‘sprints’.
In total, Ben identified eight strategies to fold into the working life of the team.
It was important that all team behaviours were developed by the team. The behaviours were supported by rules that exist to support achievement of goals by maximising performance.
For the Olympic rowing team, the rules were created, changed and dropped by the team depending on whether or not they were seen to make the boat go faster. Business analysts might do something similar with development methods and approaches, techniques and standards.
The rules were :
- Constantly discussed
- Bought into by everybody
The parallels to agile team work are obvious.
It’s not what you do it’s the way that you do it
Focus on the process
One interesting recommendation is to concentrate not on the result, but on the process that delivers that result.
Within a process there are variables that can be changed and experimented with to see what really does make the boat go faster.
Teams must discover what works for them, for their type of project in their industry, their organisation, culture, management policy.
Throw away the rule book
In the world of the business analyst, this could well mean throwing away the standard rule (recipe) book and devising your own approach. Remember to measure everything to ensure that your approach is bringing you closer to the finishing line and the achievement of your goals.
Give it some wellie
Ben recommends discussing the variables and agreeing as a team which variable or subset of the variables should be focused on for the next few weeks. Work smarter, not harder or longer. Get really focused for brief periods, then meet and reflect.
When the going gets tough, the tough get …. gone ?
Of course working in a team, as with any relationship, has its challenges. Everyone who has worked in a high performing team which demonstrates great motivation, moral and results knows how great it can be to be a member.
- But what happens when the membership of that team changes ?
- What happens if there is one person not pulling their weight or one person that you really wish would find somewhere else to work ?
Such things can and will slow down the boat. Strategies are needed to deal with them and to turn negatives into positives. The book contains advice for handling these situations.
Start as you mean to go on
Success starts by setting goals, big crazy goals and smaller, measurable and achievable goals.
Measure all the time and change your process according to what works for you and your team ; do not change just to fit in with the prevailing wisdom.
- Only you and your team know what works for you
- Only you and your team know the constraints that your environment forces on you
- Only you and your team know each other’s strengths and weaknesses, personalities, attitudes and biases
As is advised in many Kanban circles, start from where you are and then go for continuous improvement, one bit at a time. Focus on what really does make your boat go faster.
Want to read the book for yourself?
To read reviews of ‘Will it make the boat go faster’ on Amazon and perhaps purchase a copy (either for Kindle, as shown, or in paperback), please click the banner below.
Disclaimer: If you purchase a copy of the book by following the link below, Capiro will receive a small ‘royalty’ from Amazon.