Business Analyst Foundation Certification

1. Documenting and Managing Requirements

1.1. The requirements document

1.1.1. Structure

1.1.2. Content of the requirements document

1.2. The requirements catalogue

1.2.1. Types of requirements; general, technical, functional and non-functional

1.2.2. Hierarchy of requirements

1.2.3. Documenting a requirement

1.3. Managing requirements

1.3.1. Elements of requirements management

2. Modelling Requirements

2.1. Modelling system functions

2.1.1. Use case diagrams

2.2. Modelling system data

2.2.1. Entity Relationship Diagrams

2.2.1.1. Entities, attributes and relationships

2.2.1.2. Types of relationships

2.2.2. Class Models

2.2.2.1. Objects and classes

2.2.2.2. Attributes

2.2.2.3. Associations

3. Delivering the Requirements

3.1. Delivering the solution

3.2. Context

3.2.1. The context for the organisation and the project will provide the basis for deciding how any business changes are to be delivered.

3.2.2. The key factors to take into account are as follows:

3.2.2.1. The culture and underlying philosophy of the organisation

3.2.2.2. The business context for the proposed changes

3.2.2.3. Any constraints that impinge upon the project

3.2.2.4. The prioritised needs of the business

3.2.2.5. The drivers for the project

3.3. Lifecycles

3.3.1. The waterfall lifecycle

3.3.2. The ‘V’ model lifecycle

3.3.3. Incremental lifecycle

3.3.4. Iterative systems development lifecycle

4. Delivering the Business Solution

4.1. BA role in the business change lifecycle

4.2. Design stage

4.2.1. Information and Technology

4.2.1.1. Development

4.2.1.2. Testing

4.2.1.3. Design

4.3. Implementation stage

4.3.1. SARAH model

4.4. Realisation stage

4.4.1. Contents of the benefits plan

5. Making a Business and Financial Case

5.1. The business case in the project lifecycle

5.2. Identifying options

5.3. Assessing project feasibility

5.3.1. There are many issues to think about in assessing feasibility but all fall under the three broad headings

5.3.1.1. Business feasibility

5.3.1.1.1. The proposal matches the business objectives and strategy of the organisation and – if it is a commercial firm – if it can be achieved in the current market conditions.

5.3.1.2. Technical feasibility

5.3.1.2.1. The proposed solution must meet the organisation’s demands in terms of system performance, availability, reliability, maintainability and security.

5.3.1.3. Financial feasibility

5.3.1.3.1. The organisation can afford the proposed solution. There may already be a budget imposed. The organisation needs either to have the required funds available or to be in a position to borrow them.

5.3.2. PESTLE analysis can be used in assessing feasibility to examine the environment outside an organisation. It can be used to assess feasibility like this:

5.3.2.1. Political: Is the proposed solution politically acceptable?

5.3.2.2. Economic: Can the organisation afford the solution?

5.3.2.3. Socio-cultural: Does the solution fit with the organisation’s culture?

5.3.2.4. Technological: Can the solution be achieved, technically?

5.3.2.5. Legal: Is it legal, will the regulator allow it?

5.3.2.6. Environmental: Does it raise any ‘green’ environmental issues?

5.3.3. A final tool that can be employed to assess the feasibility of an option is a ‘force-field analysis’.

5.3.3.1. We consider those forces inside and outside the organisation that will support adoption of the proposal and those that will oppose it.

5.3.3.2. We need to be sure that the positive forces outweigh the negative.

5.3.3.3. The forces may include the PESTLE factors mentioned above and also the key stakeholders in the organisation.

5.3.3.4. If we conclude that the negative forces are just too strong, then the proposal is not feasible and must be abandoned or re-cast in a way that gets more positive forces behind it.

5.3.4. In considering the feasibility of options, we also need to think about their impacts and risks.

5.4. Structure of a business case

5.4.1. Contents of a business case

5.4.2. Categories of costs and benefits

5.4.3. Impact assessment

5.4.4. Risk assessment

5.5. Investment appraisal

5.5.1. Payback

5.5.1.1. Payback calculations have the virtue of being easy to understand and relatively easy to construct.

5.5.1.2. Where interest rates and inflation are low they provide a reasonable forecast of what will happen.

5.5.1.3. However, they do not take account of what accountants call the ‘time value of money’.

5.5.2. Discounted cash flow (DCF) or ‘net present value’ (NPV)

5.5.2.1. A method that takes account of the time value of money is known as discounted cash flow (DCF) which leads to a ‘net present value’ (NPV) for the project.

5.5.2.2. This means that all of the cash-flows in years after Year 0 are adjusted to today’s value of money.

5.5.2.3. Management accountants work out the ‘discount rate’ to use in a discounted cash flow calculation by studying a number of factors including the likely movement of money-market interest rates in the next few years.

5.5.3. Internal rate of return

5.5.3.1. This is a calculation that assesses what sort of return on investment is represented by the project in terms of a single percentage figure.

5.5.3.2. This can then be used to compare projects one with another to see which are the better investment opportunities, and to compare them all with what the same money could earn if just left in the bank.

5.5.3.3. So, for example, if the IRR of a project is calculated at three per cent and current bank interest rates are five per cent, then on financial grounds alone it would be better not to spend the money.

5.5.3.4. IRR is worked out by standing the DCF/NPV calculations on their head. The question we are asking is, what discount rate would we have to use to get a net present value of zero after five years (or whatever period the organisation mandates should be used for the calculation)?

5.5.3.5. In other words, at what point would financial costs and benefits precisely balance each other? For example, trying different discount rates until an NPV of zero is produced.

6. Establishing the Requirements

6.1. A framework for requirements engineering

6.1.1. The requirements engineering encapsulates a more disciplined and rigorous approach to requirements definition.

6.1.2. The business analyst should follow a roadmap that guides them through the key steps required to develop a well-defined requirements document.

6.1.3. Requirements elicitation is concerned with drawing out information and requirements from the business stakeholders, using a toolkit of techniques to undertake requirements elicitation effectively.

6.1.4. Requirements analysis stage focuses on examining and organising the elicited requirements and the business analyst verify carefully to ensure that initial requirements are well formed "SMART".

6.1.5. Once the set of unique requirements have been identified, it is important to check them against the business objectives.

6.1.6. The business analyst has a gatekeeper role, ensuring only those requirements that pass the scrutiny will be entered in the document.

6.1.7. This iterative process continues until the analyst is content that the requirements have been defined to the desired level of detail and quality.

6.1.8. Requirements validation involves the external stakeholders reviewing the requirements in order to agree and sign off the requirements document.

6.1.9. Requirements documentation is concerned with the development of a well-organised requirements document.

6.1.10. Requirements management covers the activities needed to manage any changes to the requirements.

6.2. Actors in requirements engineering

6.2.1. The business representatives

6.2.2. The project team

6.3. Requirements elicitation

6.3.1. Tacit and explicit knowledge

6.3.2. Requirements elicitation techniques

6.4. Requirements analysis

6.4.1. Requirements filters

6.4.2. SMART requirements

6.5. Requirements validation

7. Bibliographic reference

7.1. Book: Business Analysis, Third edition

7.2. Editors: Debra Paul, James Cadle and Donald Yeates

7.3. Published by BCS Learning & Development Ltd

8. What is Business Analyst?

8.1. The origins of business analysis

8.1.1. Developments in IT have enabled organisations to create information systems that have improved business operations and management decision making.

8.1.2. Technology has enabled new business models to be implemented through more flexible communication mechanisms that allow organisations to reach out to the customer.

8.1.3. The use of IT has also created opportunities for organisations to focus on their core processes and competencies.

8.1.4. IT projects continuing to overrun their budgets by significant amounts and poor communication between business and technical experts remaining problematic.

8.2. The development of business analysis

8.2.1. The impact of outsoursing

8.2.1.1. The outsourcing business model has undoubtedly been a catalyst for the development of the business analysis function.

8.2.2. Competitive advantage of using IT

8.2.2.1. The growing recognition that three factors need to be present in order for the IT systems to deliver competitive advantage.

8.2.2.1.1. First, the needs of the business must drive the development of the IT systems;

8.2.2.1.2. Second, the implementation of an IT system must be accompanied by the necessary business changes;

8.2.2.1.3. Third, the requirements for IT systems must be defined with rigour and accuracy.

8.2.3. Successful business change

8.2.3.1. During the last few years, organisations have adopted a broader view – from IT projects to business change programmes.

8.2.3.2. There has been recognition of the need for roles and skill sets that enable the successful delivery of business change initiatives.

8.2.3.3. The business analyst role – one that uncovers the root causes of problems, identifies the issues to be addressed and ensures any solution will align with business needs – should be well defined, with a clear statement of their scope and focus within the business change lifecycle.

8.2.4. The importance of the business analyst

8.2.4.1. The delivery of predicted business benefits, promised from the implementation of IT, has proved to be extremely difficult, with the outsourcing of IT services serving to add complication to already complex situations.

8.2.4.2. Organisations also want help in finding potential solutions to business issues and opportunities, sometimes where IT may not prove to be the answer.

8.2.4.3. These factors have led directly to the development of the business analyst role.

8.2.4.4. we need also to recognise the potential this can offer, particularly in a global economic environment where budgets are limited and waste of financial resources unacceptable.

8.2.5. Business analysts as internal consultants

8.2.5.1. External consultant

8.2.5.1.1. Advantages

8.2.5.1.2. Disadvantages

8.2.5.2. Internal consultant

8.2.5.2.1. Advantages

8.2.5.2.2. Disadvantages

8.3. The scope of business analysis work

8.3.1. The range of analysis activities

8.3.1.1. Strategy analysis and Definition

8.3.1.1.1. Some business analysts may be required to undertake strategic analysis and identify business transformation actions

8.3.1.2. IT system analysis

8.3.1.2.1. Systems analysts are responsible for analysing and specifying the IT system requirements

8.3.1.3. Business analysis

8.3.1.3.1. Business analysts will usually be required to investigate a business system where improvements are required but the range and focus of those improvements can vary considerably.

8.3.2. Realising business benefits

8.3.2.1. The analyst may also be required to help develop a business case in order to justify the required level of investment and ensure any risks are considered.

8.3.3. Taking a holist approach

8.3.3.1. The business analyst performs a key role in supporting management’s exploitation of IT to obtain business benefit.

8.3.3.2. All aspects of the operational business system need to be analysed if all of the opportunities for business improvement are to be uncovered.

8.3.3.3. The POPIT model shows the different views that must be considered when identifying areas for improving the business system.

8.3.3.3.1. Processes

8.3.3.3.2. Organisation

8.3.3.3.3. People

8.3.3.3.4. Information

8.3.3.3.5. Technology

8.3.4. Agile systems development

8.3.4.1. The Agile philosophy is to deliver software increments early and to elaborate requirements using approaches such as prototyping.

8.3.4.2. The Agile Manifesto stated:

8.3.4.2.1. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

8.3.4.2.2. Individuals and interactions over processes and tools;

8.3.4.2.3. Working software over comprehensive documentation;

8.3.4.2.4. Customer collaboration over contract negotiation;

8.3.4.2.5. Responding to change over following a plan.

8.3.4.2.6. That is, while there is value in the items on the right, we value the items on the left more.

8.3.4.3. The analyst will be involved in supporting the business users in clarifying, elaborating and prioritising the requirements during the development process.

8.3.5. Supporting business change

8.3.5.1. The implementation of business change may require extensive support from the business analysts, including tasks such as:

8.3.5.1.1. writing procedure manuals and user guides;

8.3.5.1.2. training business staff in the use of the new processes and IT systems;

8.3.5.1.3. defining job roles and writing job role descriptions;

8.3.5.1.4. providing ongoing support as the business staff begin to adopt the new, unfamiliar, approaches.

8.4. The role and resposibilities of a business analyst

8.4.1. Definition of the business analyst role

8.4.1.1. An advisory role which has the responsibility for investigating and analysing business situations, identifying and evaluating options for improving business systems, elaborating and defining requirements, and ensuring the effective implementation and use of information systems in line with the needs of the business.

8.4.2. Further aspects of the business analyst role

8.4.2.1. So where does this leave us in defining the role and responsibilities of a business analyst?

8.4.2.2. These core responsibilities are:

8.4.2.2.1. Investigate business system, taking holistic view of the situation.

8.4.2.2.2. Evaluate actions to improve the operation of a business system.

8.4.2.2.3. Document the business requirements for the IT system support using appropriate documentation standards.

8.4.2.2.4. Elaborate requirements, in support of the business users, during evolutionary system development.

8.4.2.3. These areas are where business analysts are in a more senior role:

8.4.2.3.1. Strategy implementation

8.4.2.3.2. Business case prodution

8.4.2.3.3. Benefits realisation

8.4.2.3.4. Specification of IT requirements

8.4.2.4. The rationale for business analysis is:

8.4.2.4.1. Root cause, not symptoms

8.4.2.4.2. Business improvements, not IT change

8.4.2.4.3. Options, not solution

8.4.2.4.4. Feasible and contributing requirements, not all requests

8.4.2.4.5. The entire business change lifecycle, not just requirements definition

8.4.2.4.6. Negotiation of conflicts, not avoidance

8.5. The business analysis maturity model (BAMM) = Scope X Authority

8.5.1. Scope LOW & Authority LOW = System Improvement

8.5.2. Scope SOME & Authority SOME = Process Improvement

8.5.3. Scope HIGH & Authority HIGH = Business Improvement

8.6. The factors that support business analyst as profession

8.6.1. Qualifications

8.6.2. Standards

8.6.3. Continuing professional development

8.6.4. Professional body

9. The Competencies of a Business Analyst

9.1. Competencies

9.1.1. Personal Qualities

9.1.1.1. Communication

9.1.1.2. Relationship

9.1.1.3. Influencing

9.1.1.4. Team work

9.1.1.5. Political awareness

9.1.1.6. Analytical skill and critical thinking

9.1.1.7. Attention to detail

9.1.1.8. Problem solving

9.1.1.9. Leadership

9.1.1.10. Self-confidence

9.1.1.11. Personal development

9.1.2. Business Knowledge

9.1.2.1. Business finance

9.1.2.2. Business case development

9.1.2.3. Domain knowledge

9.1.2.4. Subject matter expertise

9.1.2.5. IT principles

9.1.2.6. Organizational structures

9.1.2.7. Supplier management

9.1.2.8. Business architeture

9.1.3. Professional Techniques

9.1.3.1. Project management

9.1.3.2. Strategy Analysis

9.1.3.3. Stakeholder analysis and management

9.1.3.4. Investigation techniques

9.1.3.5. Requirements engineering

9.1.3.6. Business modeling

9.1.3.7. Data modeling

9.1.3.8. Gap analysis

9.1.3.9. Facilitation skills

9.1.3.10. Portifolio managements

9.1.3.11. Benefits managements

9.1.3.12. Agile thinking

9.2. Development of competencies

9.2.1. SFIA - Skills Framework for the Information Age

9.2.1.1. Level of skill

9.2.1.1.1. Follow

9.2.1.1.2. Assist

9.2.1.1.3. Apply

9.2.1.1.4. Enable

9.2.1.1.5. Ensure & Advice

9.2.1.1.6. Initiate & Influence

9.2.1.1.7. Set strategy, Inspire & Mobilise

9.2.1.2. Categories

9.2.1.2.1. Strategy & Architeture

9.2.1.2.2. Change & Transformation

9.2.1.2.3. Development & Implementation

9.2.1.2.4. Delivery & Operation

9.2.1.2.5. Skill & Quality

9.2.1.2.6. Relationship & Engagement

9.2.2. The Business analyst in the SFIA is in the category "Change & Tranformation"and the skil can range between 3 to 6.

9.2.3. Skill analysis matrix (What x How - knowledge about the problem)

9.2.3.1. What is High and How is High then the level might be 3-4

9.2.3.2. What is High and How is LOW then the level might be 4-5

9.2.3.3. What is LOW and How is High then the level might be 4-5

9.2.3.4. What is LOW and How is LOW then the level might be 6

9.3. How to develop the competencies

9.3.1. Trainning

9.3.2. Self study

9.3.3. Work experience

9.3.4. Professional certification

10. Strategy Analysis

10.1. The context for strategy

10.1.1. Why do organisations bother about strategy? What advantage do they hope to gain?

10.1.2. Most of us would probably support the idea that business is becoming increasingly unpredictable and changes are more turbulent,

10.1.3. There are some big changes that organisations face and that strategy development tries to moderate:

10.1.3.1. There are the changes to the ways that we are employed.

10.1.3.2. Society has changed.

10.1.3.3. Organisations are responding to these changes by doing everything they can to increase their flexibility and responsiveness.

10.1.3.4. The world is full of contradictions.

10.1.3.4.1. Global versus local.

10.1.3.4.2. Centralised versus decentralised organisation structures.

10.1.3.4.3. Hard and soft management.

10.2. The definition of strategy

10.2.1. A popular definition appears in Johnson, Scholes and Whittington (2008):

10.2.1.1. Strategy is the direction and scope of an organisation over the long term, which achieves advantage in a changing environment through its configuration of resources and competences with the aim of fulfilling stakeholder expectations.

10.2.2. Johnson, Scholes and Whittington (2008) provide a helpful definition of the issues to be considered during strategy analysis. These are:

10.2.2.1. the long-term direction of an organisation;

10.2.2.2. the scope of an organisation’s activities;

10.2.2.3. advantage for the organisation over competition;

10.2.2.4. strategic fit with the business environment;

10.2.2.5. the organisation’s resources and competences;

10.2.2.6. the values and expectations of powerful actors.

10.2.3. Typical levels of strategy could be

10.2.3.1. Corporate Strategy

10.2.3.1.1. Concerned with the overall purpose and scope of the business.

10.2.3.2. Business Unit Strategy

10.2.3.2.1. Below the corporate level are the strategic business units (SBUs).

10.2.3.3. Operational Strategy

10.2.3.3.1. Focuses on the delivery of the corporate and SBU strategies.

10.3. Strategy development

10.3.1. Strategy may be formulated in different ways. For example:

10.3.1.1. Strategy associated with an individual, often the founder of a business.

10.3.1.2. Strategy may develop from the experiences and views of internal managers.

10.3.1.3. Strategy emerges from the people who do the work.

10.3.1.4. Strategy by adopting a formal, carefully planned, design process.

10.3.2. Another force that may drive strategy formulation is the politics within the organisation. This force comes from five main sources:

10.3.2.1. Dependency

10.3.2.1.1. Departments are dependent on those departments that have control over the organisation’s resources.

10.3.2.2. Financial resources

10.3.2.2.1. Where are the funds to invest in the development of new ideas, products or services? Who has these funds?

10.3.2.3. Position

10.3.2.3.1. Where do the actors live in the organisation structure and how does their work affect the organisation’s performance?

10.3.2.4. Uniqueness

10.3.2.4.1. No other part of the organisation can do what the powerful group does.

10.3.2.5. Uncertainty

10.3.2.5.1. Power resides with people and groups can cope with the unpredictable effects of the environment and protect others from its impact.

10.3.3. Once a strategy has been developed, it is important to provide a written statement of the strategy:

10.3.3.1. it provides a focus for the organisation and enables all parts of it to understand the reasons behind top-level decisions and how each part can contribute to its achievement;

10.3.3.2. it provides a framework for a practical allocation of investment and other resources;

10.3.3.3. it provides a guide to innovation, where new products, services or systems are needed;

10.3.3.4. it enables appropriate performance measures to be put in place that measure the key indicators of our success in achieving the strategy;

10.3.3.5. it tells the outside world, especially our outside stakeholders and market analysts, about us and develops the expectations that they hold.

10.4. External environment analysis

10.4.1. Organisations face a complex and changing external environment of increasing unpredictability.

10.4.2. PESTLE analysis - help organisations assess their broad environment.

10.4.2.1. Political influences

10.4.2.1.1. The stability of the government or political situation

10.4.2.1.2. Government policies – such as on social welfare

10.4.2.1.3. Trade regulations and tariffs

10.4.2.2. Economic influences

10.4.2.2.1. Interest rates

10.4.2.2.2. Money supply

10.4.2.2.3. Inflation

10.4.2.2.4. Unemployment

10.4.2.2.5. Disposable income

10.4.2.2.6. Availability and cost of energy

10.4.2.2.7. The internationalisation of business

10.4.2.3. Socio-cultural influences

10.4.2.3.1. Demographics – such as an ageing population in Europe

10.4.2.3.2. Social mobility – will people move to find work or stay unemployed where they are and rely on state support?

10.4.2.3.3. Lifestyle changes – such as changes in the retirement age

10.4.2.4. Technological influences

10.4.2.4.1. Technological developments

10.4.2.4.2. Government spending on research

10.4.2.4.3. The focus on technology; demand for invention and innovation

10.4.2.4.4. The pace of technological change, the creation of technology enabled industries

10.4.2.5. Legal influences

10.4.2.5.1. Legislation about trade practices and competition

10.4.2.5.2. Employment law – employment protection, discrimination etc

10.4.2.5.3. Health and safety legislation

10.4.2.5.4. Company law

10.4.2.5.5. Financial regulation

10.4.2.6. Environmental influences

10.4.2.6.1. Global warming and climate change

10.4.2.6.2. Animal welfare

10.4.2.6.3. Waste, such as unnecessary packaging

10.4.2.6.4. Environmental protection legislation such as new laws on recycling and waste disposal industries

10.4.3. Porter’s five forces model - evaluate an industry’s profitability and hence its attractiveness (Porter 1980)

10.4.3.1. New entrants may want to move into the market...but there are barriers to entry that organisations build. These include:

10.4.3.1.1. Economies of scale.

10.4.3.1.2. Substantial investment required.

10.4.3.1.3. Product differentiation.

10.4.3.1.4. Access to distribution channels.

10.4.3.1.5. The existence of patented processes.

10.4.3.1.6. The need for regulatory approval.

10.4.3.2. Supplier power limits the opportunity for cost reductions when

10.4.3.2.1. there is a concentration of suppliers and when supplying businesses are bigger than the many customers they supply

10.4.3.2.2. the costs of switching from one supplier to another are high.

10.4.3.2.3. the supplier brand is powerful.

10.4.3.2.4. customers are fragmented so do not have a collective influence.

10.4.3.3. Customer power – or the bargaining power of buyers as Porter called it – is high when

10.4.3.3.1. there are many small organisations on the supply side.

10.4.3.3.2. alternative sources of supply are available and easy to find;

10.4.3.3.3. the cost of the product or service is high, encouraging the buyer to search out alternatives;

10.4.3.3.4. switching costs are low.

10.4.3.4. The threat from substitute products is high when:

10.4.3.4.1. product substitution from new technologies is more convenient;

10.4.3.4.2. the need for the product may be replaced by meeting a different need;

10.4.3.4.3. it is possible to decide to ‘do without it’!

10.4.3.5. There may also be high competitive rivalry when

10.4.3.5.1. there are many competing firms;

10.4.3.5.2. buyers can easily switch from one firm to another;

10.4.3.5.3. the market is growing only slowly or not growing at all;

10.4.3.5.4. the industry has high fixed costs and responding to price pressure is difficult;

10.4.3.5.5. products are not well differentiated or are commoditised so there is little brand loyalty;

10.4.3.5.6. the costs of leaving the industry are high.

10.4.4. ‘what if?’ questions

10.4.4.1. There is a high level of uncertainty and some different approaches are needed to understand potential future impacts. Scenarios may be used to do this.

10.4.4.2. They begin by identifying the potential high impact and high uncertainty factors in the environment.

10.4.4.3. It is tempting to choose just two scenarios – good and bad – when doing this, but really four or more are needed and they should be plausible and detailed.

10.5. Internal environment analysis

10.5.1. Successful strategies depend on the capability of the organisation to perform.

10.5.2. MOST analysis - understanding of the current business positioning

10.5.2.1. We can define the MOST terms as follows:

10.5.2.1.1. Mission

10.5.2.1.2. Objectives

10.5.2.1.3. Strategy

10.5.2.1.4. Tactics

10.5.2.2. When considering the MOST analysis as a means of identifying strengths and weaknesses:

10.5.2.2.1. Is the MOST clearly defined? For example, are the objectives well-formed and SMART (Specific, Measurable, Achievable, Relevant and Time framed)?

10.5.2.2.2. Is there congruence between elements of the SWOT (strengths, weaknesses, opportunities, threats)(see below)? For example, is the strategy aligned with the objectives?

10.5.2.2.3. Has the MOST been communicated to the managers and staff of the organisation?

10.5.3. Resource Audit - can help us to identify core competences.

10.5.3.1. or may highlight where there is a lack of competence that could undermine any competitive moves.

10.5.3.2. There are five key areas to examine, the first three being sets of tangible resource and the other two being sets of intangible resource.

10.5.3.2.1. Tangible resource:

10.5.3.2.2. Intangible Resource:

10.5.4. Boston Box - provides a means of conducting portfolio analysis

10.5.4.1. Developed by the Boston Consulting Group.

10.5.4.2. The relationship between the SBU’s current or future revenue potential is modelled against the current share of the market.

10.5.4.3. Enable organisations to categorise their SBUs and their products/services, and thereby consider whether and how much to invest.

10.5.4.4. Put simply, the cows are milked, the dogs are buried, the stars get the gold and the wild cats are carefully examined until they behave themselves or join the dogs and die.

10.5.4.4.1. The Cash Cows are the mature products or services, in markets with little, if any, growth.

10.5.4.4.2. The Stars strengthen their position in a growth industry until they become the big profit earners.

10.5.4.4.3. The Wild Cats (or Problem Children) are unprofitable but are investments for the future.

10.5.4.4.4. The Dogs have low market share in markets with low growth and are often the areas that are removed.

10.5.4.5. The Stars and Cash Cows provide the funding for the other segments of the matrix.

10.6. SWOT analysis

10.6.1. Pull together the results of an analysis of the external and internal environments.

10.6.2. Summarise the key strengths, weaknesses, pportunities and threats in order to carry out an overall audit of the strategic position of a business and its environment.

10.6.3. Format of a SWOT matrix

10.6.3.1. Strengths: Internal and Positive

10.6.3.2. Weakness: Internal and Negative

10.6.3.3. Opportunity: External and Positive

10.6.3.4. Threat: External and Negative

10.7. Executing strategy

10.7.1. Executing new strategies implies risk because it involves change.

10.7.2. There are five contextual issues to be considered.

10.7.2.1. Time

10.7.2.1.1. how quickly does the new strategy need to be implemented? What pace of change is needed?

10.7.2.2. Scope

10.7.2.2.1. how big is the change? Is the new strategic direction transformational or incremental?

10.7.2.3. Capability

10.7.2.3.1. does the organisation have the required resources for the change? is the organisation adaptable and able to change? Are the experiences of change positive or negative?

10.7.2.4. Readiness

10.7.2.4.1. is the whole organisation, or the part of it to be affected, ready to make the change?

10.7.2.5. Strategic leadership

10.7.2.5.1. is there a strategic leader for the change?

10.7.3. The strategic leader will have the key role and needs to demonstrate the following key characteristics:

10.7.3.1. Challenges the status quo all the time and sets new and demanding targets.

10.7.3.2. Establishes and communicates a clear vision of the direction to be taken.

10.7.3.3. ‘Models the way’ or ‘Walks the walk’.

10.7.3.4. Empowers people to deliver their part of the strategic change within the vision.

10.7.3.5. Celebrates success with those who achieve it.

10.7.4. Two tools that help in the execution of strategy

10.7.4.1. The McKinsey 7-S model

10.7.4.1.1. These are the seven levers, often described as ‘hard’ and ‘soft’ components and they are all interlinked.

10.7.4.1.2. All seven need attention if the strategy is to be executed successfully. Changing one element, means that all of the others have to change as well.

10.7.4.2. The Balanced Business Scorecard

10.7.4.2.1. The emphasis of the scorecard is to measure aspects of performance in a balanced way.

10.7.4.2.2. In the past, managers have perhaps paid more attention to the financial measures.

10.7.4.2.3. The BBS shows it is important to consider all of the four aspects and answers questions like these:

10.7.5. Critical Success Factors and Key Performance Indicators

10.7.5.1. The BBS helps in the definition of CSFs and KPIs which are vital to assess business performance.

10.7.5.2. It’s important that KPIs are defined as SMART and that they are monitored regularly.

11. The Business Analysis Process Model

11.1. An approach to problem-solving

11.1.1. Mess finding

11.1.1.1. where we often begin when undertaking a problem investigation.

11.1.2. Data finding

11.1.2.1. concerned with analysing the opinions, concerns, knowledge and ideas uncovered in the previous stage.

11.1.3. Problem finding

11.1.3.1. uses the work of the previous two stages to help uncover the heart of the problem.

11.1.4. Idea finding

11.1.4.1. which business analysts try to generate a wide range of ideas.

11.1.5. Solution finding

11.1.5.1. they can be evaluated and we can focus on those that could provide solutions to the problem(s).

11.1.6. Acceptance finding

11.1.6.1. concerned with gaining business acceptance of the solution.

11.2. The Business Analysis process model shows the importance of understanding the business context. We need to be aware of the Mission, Objective, Strategy and Tactics (MOST).

11.3. Stages of the business analysis process model

11.3.1. Investigate situation

11.3.1.1. Objectives

11.3.1.1.1. Concerned with uncovering issues and problems.

11.3.1.1.2. The OSCAR mnemonic can be very useful when clarifying the terms of reference if none exist.

11.3.1.2. Procedure

11.3.1.2.1. Study background material – project initiation document, terms of reference

11.3.1.2.2. Carry out initial investigation with key stakeholders

11.3.1.2.3. Document the results of the investigation – using meeting reports plus diagrams such as a ‘rich picture’, mind-map or fishbone diagrams

11.3.1.3. Inputs

11.3.1.3.1. Terms of reference or project initiation document

11.3.1.3.2. MOST, statement of business values

11.3.1.4. Outputs

11.3.1.4.1. View of the existing business situation, including meeting reports and diagrams such as rich pictures, mind maps and fishbone diagrams

11.3.1.4.2. List of issues/problems

11.3.1.5. Techniques

11.3.1.5.1. Investigation techniques such as interviewing, observation and workshops

11.3.1.5.2. Quantitative investigation techniques such as surveys, sampling and document analysis

11.3.1.5.3. ‘Rich pictures’

11.3.1.5.4. Mind maps

11.3.1.5.5. Spaghetti maps

11.3.1.5.6. Fishbone diagrams

11.3.1.5.7. Business process models

11.3.2. Consider perspectives

11.3.2.1. Objectives

11.3.2.1.1. Take stock of the range of stakeholder perspectives about the business system under investigation.

11.3.2.1.2. These perspectives may then be analysed to uncover stakeholder values and beliefs, and developed into business activity models.

11.3.2.2. Procedure

11.3.2.2.1. Identify key stakeholders whose perspectives are important to the business analysis project

11.3.2.2.2. Investigate the values, beliefs and priorities of the key stakeholders

11.3.2.2.3. Develop and analyse the stakeholder perspectives

11.3.2.2.4. Build conceptual models of activities to fulfil the stakeholder perspectives

11.3.2.2.5. Explore and resolve conflicts between stakeholder perspectives

11.3.2.2.6. Synthesise conceptual models into one view of the desired business system

11.3.2.3. Inputs

11.3.2.3.1. Terms of reference or project initiation document

11.3.2.3.2. Business values and MOST

11.3.2.3.3. Identified stakeholders (from the documentation of the existing business system)

11.3.2.4. Outputs

11.3.2.4.1. Power/Interest grid

11.3.2.4.2. Stakeholder perspectives

11.3.2.4.3. Business activity models based upon stakeholder perspectives

11.3.2.4.4. Consensus business activity model

11.3.2.5. Techniques

11.3.2.5.1. Investigation and negotiation techniques

11.3.2.5.2. Stakeholder identification and analysis

11.3.2.5.3. CATWOE

11.3.2.5.4. Business Activity Modelling (BAM)

11.3.3. Analyse needs

11.3.3.1. Objectives

11.3.3.1.1. Explore the differences between the current and desired situations.

11.3.3.1.2. Identify the opportunities for business change by analysing these differences or ‘gaps’.

11.3.3.2. Procedure

11.3.3.2.1. Examine the activities on the business activity model

11.3.3.2.2. Consider how well each activity is carried out in the current business system and how well it is supported by the organisation’s information systems

11.3.3.2.3. Identify the key business events to be handled within the business system; develop ‘as is’ business process models for the key business events

11.3.3.2.4. Develop ‘to be’ business process models for the key business events

11.3.3.2.5. Analyse the gaps between the existing and the desired business systems. Use these as a basis for identifying potential business system improvements

11.3.3.2.6. Ensure any potential improvements align with the business architecture

11.3.3.3. Inputs

11.3.3.3.1. Agreed business activity model

11.3.3.3.2. View of the existing business system

11.3.3.3.3. Business values and MOST

11.3.3.4. Outputs

11.3.3.4.1. Analysis of activities, including identified areas of weakness

11.3.3.4.2. ‘As is’ and ‘to be’ business process models

11.3.3.4.3. List of potential improvements to the business system

11.3.3.5. Techniques

11.3.3.5.1. Gap analysis

11.3.3.5.2. Activity analysis

11.3.3.5.3. Business process modelling

11.3.4. Evaluate options

11.3.4.1. Objectives

11.3.4.1.1. Collect together the range of potential changes into packages of improvement actions.

11.3.4.1.2. These packages form the basis for developing a set of options.

11.3.4.1.3. They are then presented to business managers for consideration.

11.3.4.2. Procedure

11.3.4.2.1. Identify range of business options

11.3.4.2.2. Explore acceptability of options and reduce to a shortlist

11.3.4.2.3. Develop and document each option in detail. In particular, consider the business, technical and financial feasibility of each option

11.3.4.2.4. Develop business case, including presenting options and recommendations to business managers

11.3.4.3. Inputs

11.3.4.3.1. Project initiation document/terms of reference

11.3.4.3.2. Business values and MOST

11.3.4.3.3. List of potential improvements to the business system

11.3.4.4. Outputs

11.3.4.4.1. Shortlist of business options

11.3.4.4.2. Business case including options, feasibility assessment and recommendations

11.3.4.5. Techniques

11.3.4.5.1. Evaluate

11.3.4.5.2. Business options identification

11.3.4.5.3. Cost-benefit analysis, including quantification of costs and benefits; investment appraisal techniques

11.3.4.5.4. Impact analysis

11.3.4.5.5. Risk analysis

11.3.5. Define requirements

11.3.5.1. Objectives

11.3.5.1.1. Produce a well-formed requirements document setting out the business requirements for the new business system.

11.3.5.1.2. This document must include clear textual descriptions of the requirements and sufficient information to trace each requirement.

11.3.5.1.3. Modelling techniques may be used to represent the process and data requirements diagrammatically and hence improve the rigour and clarity.

11.3.5.2. Procedure

11.3.5.2.1. Gather the requirements:

11.3.5.2.2. Document the requirements for the new business system, including as appropriate:

11.3.5.3. Inputs

11.3.5.3.1. Selected option for revised business system

11.3.5.3.2. Business values and MOST

11.3.5.3.3. Terms of reference/project initiation document

11.3.5.4. Outputs

11.3.5.4.1. To be’ process models

11.3.5.4.2. Job definitions

11.3.5.4.3. Revised organisational structure

11.3.5.4.4. Validated requirements document including:

11.3.5.5. Techniques

11.3.5.5.1. Business process modelling

11.3.5.5.2. Job design

11.3.5.5.3. Investigation techniques

11.3.5.5.4. Requirements elicitation, analysis and validation

11.3.5.5.5. Requirements documentation and management

11.3.5.5.6. IT systems modelling techniques

11.3.6. Deliver changes

11.3.6.1. Objective

11.3.6.1.1. The lifecycle and approach to be adopted to develop and deliver the changes will need to be determined.

11.3.6.1.2. The delivery of the business solution will need to consider aspects such as the emotional impact of change and the realisation of the business benefits.

11.3.6.2. Procedure

11.3.6.2.1. Decide the lifecycle and approach to be adopted

11.3.6.2.2. Design and develop the business change solution

11.3.6.2.3. Support the planning and implementation, in particular the development of the required learning materials and the delivery of training for the business staff

11.3.6.2.4. Review the predicted benefit

11.3.6.2.5. Identify any actions required to realise the benefits

11.3.6.3. Inputs

11.3.6.3.1. Business change process and organisation design

11.3.6.3.2. IT software solution

11.3.6.3.3. Business case

11.3.6.4. Outputs

11.3.6.4.1. Business change plan

11.3.6.4.2. Communication plan

11.3.6.4.3. Training approach and materials

11.3.6.4.4. Revised job roles and descriptions

11.3.6.4.5. Benefits plan

11.3.6.4.6. Benefits review document

11.3.6.5. Techniques

11.3.6.5.1. Use case descriptions

11.3.6.5.2. Decision tables

11.3.6.5.3. State charts

11.3.6.5.4. Benefits planning

12. Investigation Techniques

12.1. Prior research

12.1.1. Study website

12.1.2. Study company reports

12.1.3. Study procedure manuals and documentation

12.1.4. Study the organisation chart

12.2. Qualitative approaches

12.2.1. Interviews

12.2.1.1. A well-run interview can be vital in achieving a number of objectives. These include:

12.2.1.1.1. making initial contact with key stakeholders and establishing a basis for the business analysis work;

12.2.1.1.2. building and developing rapport with different business users and managers;

12.2.1.1.3. acquiring information about the business situation, including any issues and problems;

12.2.1.1.4. discovering different stakeholder perspectives and priorities.

12.2.1.2. There are three areas that are considered during fact-finding or requirements interviews:

12.2.1.2.1. current functions that need to be fulfilled in any new business system;

12.2.1.2.2. problems with the current operations or performance that need to be addressed;

12.2.1.2.3. additional features required from the new business system.

12.2.1.3. Advantages of interviewing

12.2.1.3.1. provides an opportunity to build a relationship with the users or clients.

12.2.1.3.2. the interview can yield important information.

12.2.1.3.3. understand different viewpoints and attitudes across the user group;

12.2.1.3.4. investigate new areas previously not mentioned;

12.2.1.3.5. identify and collect examples of documents, forms and reports the clients use;

12.2.1.3.6. appreciation of political factors that may affect how the business performs its work;

12.2.1.3.7. study the environment in which the business staff carry out their work.

12.2.1.4. Disadvantages of interviewing

12.2.1.4.1. take time and can be an expensive approach.

12.2.1.4.2. take up the interviewee’s time, and this may mean that they try to hurry the interview.

12.2.1.4.3. information provided during interviews may be an opinion from just one interviewee’s perspective.

12.2.1.4.4. Where several interviewees have different views may create a need for follow-up discussions and further investigative work.

12.2.1.5. Preparing for interviewing

12.2.1.5.1. This saves a lot of time by avoiding unnecessary explanations and also demonstrates interest and professionalism, which helps to establish a mutual respect and rapport.

12.2.1.5.2. The classic structure of who?, why?, what?, when? and where? provides an excellent framework for preparing for interviews.

12.2.1.6. Conducting the interview

12.2.1.6.1. It is important to structure interviews if the maximum amount of information is to be elicited using a basic structure.

12.2.1.7. Following up the interview

12.2.1.7.1. It is always a good idea to write up the notes of the interview as soon as possible – ideally straight away and usually by the next day.

12.2.2. Observation

12.2.2.1. Observing the workplace, and the staff carrying out their work, especially early in an investigation, is very useful in obtaining information about the business environment and the work practices.

12.2.2.2. The person being observed should be reassured that the objective is to understand the task not to judge their performance.

12.2.2.3. There are several different approaches to observation, depending upon the level and focus of interest:

12.2.2.3.1. Formal observation

12.2.2.3.2. Protocol analysis

12.2.2.3.3. Shadowing

12.2.2.3.4. Ethnographic studies

12.2.2.4. Advantages of observation

12.2.2.4.1. We obtain a much better understanding of the problems and difficulties faced by the business users.

12.2.2.4.2. Help us prepare appropriate questions for a more in-depth interview with the person responsible for that task.

12.2.2.4.3. It will help us to devise workable solutions that are more likely to be acceptable to the business.

12.2.2.5. Disadvantages of observation

12.2.2.5.1. Being observed can be rather unnerving.

12.2.2.5.2. The old saying ‘you change what you observe’ needs to be factored into the approach taken.

12.2.3. Workshops

12.2.3.1. Advantages of workshops

12.2.3.1.1. Gain a broad view of the area under investigation.

12.2.3.1.2. Increase speed and productivity.

12.2.3.1.3. Obtain buy-in and acceptance for the project.

12.2.3.1.4. Gain a consensus view or group agreement.

12.2.3.2. Disadvantages of workshops

12.2.3.2.1. Workshops can be time-consuming to organise.

12.2.3.2.2. If the workshop is not carefully facilitated, it may happen that a forceful participant will dominate the discussion.

12.2.3.2.3. It can be difficult to ensure that the participants have the required level of authority.

12.2.3.3. Preparing for the workshop

12.2.3.3.1. The success or failure of a workshop session depends in large part upon the preparatory work done.

12.2.3.3.2. They should spend time before the event planning the following areas:

12.2.3.4. Facilitating the workshop

12.2.3.4.1. The workshop should start by discussing the objective and endeavouring to secure the participants’ buy-in.

12.2.3.4.2. The facilitator needs to ensure that the issues are discussed, views are aired and progress is made towards achieving the stated objective.

12.2.3.4.3. A record needs to be kept of the key points emerging from the discussion.

12.2.3.4.4. At the end, the facilitator needs to summarise the key points and actions.

12.2.3.5. Techniques

12.2.3.5.1. Discovery techniques

12.2.3.5.2. Visualisation techniques

12.2.3.5.3. Hothouse workshop

12.2.3.5.4. Focus groups

12.2.3.6. Following the workshop

12.2.3.6.1. After the workshop any key points and actions are written up and sent to stakeholders.

12.2.3.6.2. This should be done as quickly as possible

12.2.4. Scenarios

12.2.4.1. Advantages of scenarios

12.2.4.2. Disadvantages of scenarios

12.2.4.3. Process for developing scenarios

12.2.4.3.1. Identify the task or interaction

12.2.4.3.2. Identify the steps and sequence

12.2.4.3.3. Define the control conditions

12.2.4.3.4. Identify the alternative paths

12.2.4.4. Documenting scenarios

12.2.4.4.1. A popular way of documenting scenario descriptions is to develop use case descriptions to support use case diagrams.

12.2.4.4.2. This technique is part of the Unified Modeling Language (UML) and is a textual method.

12.2.4.4.3. However, there are a number of graphical methods for documenting a scenario, such as storyboards, activity diagrams, task models and decision tree diagrams.

12.2.5. Prototyping

12.2.5.1. Important technique for eliciting, analysing, demonstrating and validating requirements.

12.2.5.2. Help business users visualise the new system and provide insight into possible requirements.

12.2.5.3. Offer a way of demonstrating how the new processes or system might work and provide a concrete basis for evaluation and discussion.

12.2.5.4. Agile software development approaches, use evolutionary prototyping as an integral part of their development lifecycle.

12.2.5.5. There is a strong link between scenarios and prototyping because scenarios can be used as the basis for developing prototypes.

12.2.5.6. Advantages of prototyping

12.2.5.6.1. to clarify any uncertainty on the part of the analysts and confirm to the user that we have understood what they asked for;

12.2.5.6.2. to help the user identify new requirements as they gain an understanding of what the system will be able to do to support their jobs;

12.2.5.6.3. to demonstrate the look and feel of the proposed system and elicit usability requirements;

12.2.5.6.4. to validate the system requirements and identify any errors;

12.2.5.6.5. to provide a means of assessing the navigation paths and system performance.

12.2.5.7. Disadvantages of prototyping

12.2.5.7.1. The prototyping cycle can spin out of control with endless iterations taking place.

12.2.5.7.2. If the purpose of the exercise has not been explained clearly, the users may think that when they are happy with the mock-up, the system is now complete and ready for use.

12.2.5.7.3. User expectations can be raised unnecessarily by failing to mimic the final appearance of the system, or its performance; If there is likely to be a delay in the real response time, it is important that you build that into the prototype.

12.3. Quantitative approaches

12.3.1. Surveys or Questionnaires

12.3.1.1. Can be useful if we need to get a limited amount of information from a lot of people and interviewing them individually.

12.3.1.2. Can be useful if we need to run a series of workshops would not be practical or cost-effective.

12.3.1.3. However, surveys are difficult to design and this has to be done with care in order to have any possibility of success.

12.3.1.4. The exact design of a survey depends upon its purpose but there are three main areas to consider:

12.3.1.4.1. heading

12.3.1.4.2. classification

12.3.1.4.3. data sections

12.3.2. Special Purpose Records

12.3.2.1. Special purpose records are data-gathering forms used by the analyst;

12.3.2.2. The format is usually decided by the analyst and they are not company records.

12.3.2.3. They can be completed either by the analyst during an observation session or given to the business users to complete.

12.3.3. Activity Sampling

12.3.3.1. Can be used when it is necessary to know how people divide their work time among a range of activities.

12.3.3.2. The results provide quantifiable data about the number of times an activity is carried out per day by the group studied.

12.3.3.3. An activity sampling exercise is carried out in five steps:

12.3.3.3.1. 1. Identify the activities to be recorded. This list should include a ‘not working’ activity as this covers breaks, and also ‘not-related’ task.

12.3.3.3.2. 2. Decide on the frequency and timings, i.e. when and how often you will record the activities being undertaken.

12.3.3.3.3. 3. Visit the study group at the times decided upon and record what each group member is doing.

12.3.3.3.4. 4. Record the results.

12.3.3.3.5. 5. After a set period, analyse the results.

12.3.4. Document Analysis

12.3.4.1. Involves reviewing samples of source documents to uncover information about an organisation, process or system.

12.3.4.2. Useful to supplement other techniques such as interviewing, workshops and observation.

12.4. Documenting the current situation

12.4.1. While the investigation of the current situation is going on, the analyst will need to record the findings, in order to understand the range of issues and the business needs.

12.4.2. Meeting reports should be produced for each interview and workshop so that they can be agreed with the participants.

12.4.3. It is also helpful to use diagrams to document the business situation.

12.4.4. This section suggests five diagrammatic techniques:

12.4.4.1. Rich pictures

12.4.4.1.1. One of the few that provide an overview of an entire business situation.

12.4.4.1.2. Modelling approaches such as data or process modelling provide a clear representation of a specific aspect of a business system.

12.4.4.1.3. Does not have a fixed notation, but allows the analyst to use any symbols or notation that are relevant and useful.

12.4.4.1.4. Can show the human characteristics of the business situation and can reflect intangible areas such as the culture of the organisation.

12.4.4.2. Mind maps

12.4.4.2.1. Useful tool for summarising a lot of information in a simple visual form that is structured to highlight connections between different ideas and topics.

12.4.4.2.2. They provide a means of organising information while, representing all of the issues that have been uncovered about the situation.

12.4.4.2.3. The business system or problem under consideration is drawn at the centre of the diagram with the main elements shown as first level of branches.

12.4.4.3. Business process models

12.4.4.3.1. In order to understand fully how a process is carried out.

12.4.4.3.2. It is helpful to draw a ‘swimlane’ diagram, which shows the tasks in a process, the actors responsible for carrying them out and the process flow.

12.4.4.3.3. Invaluable as a diagnostic aid since they help identify problems such as delays, bottlenecks and duplicate tasks.

12.4.4.4. Spaghetti maps

12.4.4.4.1. A tool to show the movement and interactions of the stakeholders in a particular environment, when performing particular tasks and processes.

12.4.4.4.2. Can be drawn up during an observation session, mapping the movements of users across the room to meet different actors or to use equipment.

12.4.4.5. Fishbone diagrams

12.4.4.5.1. A problem-analysis technique, designed to help understand the underlying causes of an inefficient process or a business problem.

12.4.4.5.2. It is similar to a mind map in some ways, but its purpose is strictly diagnostic.

12.4.4.5.3. A number of approaches may be used when labelling the spines:

13. Stakeholder Analysis and Management

13.1. Stakeholder categories and identification

13.1.1. Customers

13.1.2. Partners

13.1.3. Suppliers

13.1.4. Competitors

13.1.5. Regulators

13.1.6. Owners

13.1.7. Employees

13.1.8. Managers

13.2. Analysing stakeholders

13.2.1. Having identified the stakeholders, the next step is to make an assessment of the weight that should be attached to their issues.

13.2.2. In using the power/interest grid, it is important to plot stakeholders where they actually are.

13.3. Stakeholder management strategies

13.3.1. Power/interest grid

13.3.1.1. No or low interest and no or low power/influence

13.3.1.1.1. Ignore

13.3.1.2. Some or high interest but no or low power/influence

13.3.1.2.1. Keep informed

13.3.1.3. No or low to high interest but some power/influence

13.3.1.3.1. Keep onside

13.3.1.4. No or low interest but high power/influence

13.3.1.4.1. Whatch

13.3.1.5. Some interest and high power/influence

13.3.1.5.1. Keep satisfied

13.3.1.6. High interest and high power/influence

13.3.1.6.1. Constant, active management

13.3.2. Individuals and groups of stakeholders

13.3.2.1. Stakeholders must be considered not just as individuals but as potential groups as well.

13.3.2.2. Their ability to gain strength, particularly with the availability of social media mechanisms, should never be underestimated.

13.3.3. The stakeholders do not stay in the same place over time and so the ways they are managed must be adapted accordingly.

13.4. Managing stakeholders

13.4.1. Stakeholder plan/assessment

13.4.2. Stakeholders’ positions do not remain static during the life of a project.

13.4.3. Once stakeholders’ initial positions have been plotted, a plan should be drawn up for managing each of them and how to approach it.

13.4.4. A one-page assessment can be made for each stakeholder.

13.4.5. Useful approach would be to see all stakeholders at a glance by setting up a spreadsheet using the following headings:

13.4.5.1. Name of stakeholder

13.4.5.1.1. It may also be useful to record their current job titles.

13.4.5.2. Current power/influence

13.4.5.2.1. From the grid.

13.4.5.3. Current interest

13.4.5.3.1. From the grid.

13.4.5.4. Issues and interests

13.4.5.4.1. This is a brief summary of what interests each stakeholder and what we believe their main issues with the project are likely to be.

13.4.5.5. Current attitude

13.4.5.5.1. Champion: will actively work for the success of the project.

13.4.5.5.2. Supporter: in favour of the project but probably will not be very active in promoting it.

13.4.5.5.3. Neutral: has expressed no opinion either in favour or against the project.

13.4.5.5.4. Critic: not in favour of the project but probably not actively opposed to it.

13.4.5.5.5. Opponent: will work actively to disrupt, impede or derail the project.

13.4.5.5.6. Blocker: someone who will just obstruct progress, possibly for reasons outside of the project itself.

13.4.5.6. Desired support

13.4.5.6.1. What we would ideally like from this stakeholder, perhaps using a simple scale of high, medium or low.

13.4.5.7. Desired role

13.4.5.7.1. We may wish to get this stakeholder actively involved in the project, perhaps as the project sponsor or as part of a steering committee.

13.4.5.8. Desired actions

13.4.5.8.1. What we would like the stakeholder to do, if at all possible, to advance the project.

13.4.5.9. Messages to convey

13.4.5.9.1. This is where we define the emphasis that should be put on any communications to this stakeholder.

13.4.5.10. Actions and communications

13.4.5.10.1. This is the most important part of the plan, where we define exactly what actions we will take with regard to this stakeholder.

13.4.6. Defining stakeholder involvement by RACI and RASCI charts

13.4.6.1. A RACI chart – more formally known as a ‘linear responsibility matrix’ – lists the main products/deliverables down the side and the various stakeholders along the top.

13.4.6.2. Where a stakeholder intersects with a product, we indicate their involvement using one of the RACI categories, which mean:

13.4.6.2.1. Responsible:

13.4.6.2.2. Accountable:

13.4.6.2.3. Consulted:

13.4.6.2.4. Informed:

13.4.6.3. A RASCI chart uses a similar approach but has an additional category S for ‘support’.

13.4.6.3.1. Support:

13.4.7. Using social media in stakeholder management

13.4.7.1. Offers the business analyst additional resources to learn about stakeholders and to manage the relationships with them.

13.4.7.2. Facebook and Twitter offer a cost-effective way of communicating with large groups of people on a frequent basis and keeping them informed

13.4.7.3. This can help to build a sense of community and make people feel involved in what is going on.

13.5. Understanding stakeholder perspectives

13.5.1. Soft Systems Methodology

13.5.1.1. The basic premise underlying SSM is that real-world situations are rarely simple and are often very complex.

13.5.1.2. It is often the case that stakeholders have different views about what the ‘problem’ is and also about what needs to be done.

13.5.1.3. There are five main stages that should be applied:

13.5.1.3.1. A real-world situation to be explored

13.5.1.3.2. Stakeholders’ perspectives on the situation and the organisation

13.5.1.3.3. Conceptual models based on each perspective

13.5.1.3.4. Comparation of models with perceived real-world situation

13.5.1.3.5. Definition of actions needed to improve the situation

13.5.2. Analysing the perspectives

13.5.2.1. SSM provides us with a very useful tool that we can use to explore the stakeholders’ perspectives.

13.5.2.2. CATWOE elements is actually best done in the following order:

13.5.2.2.1. W = Weltanschauung or worldview: This summarises a stakeholder’s beliefs about the organisation or business system, which explain why it exists and what it should be doing.

13.5.2.2.2. T = Transformation: This is the principal business activity of the business system, in other words what lies at the heart of its operations.

13.5.2.2.3. C = Customer(s): Stakeholders can differ, too, in their views of who their customers are (or should be).

13.5.2.2.4. A = Actor(s): These are the people who carry out the transformation.

13.5.2.2.5. O = Owner(s): The perspective is someone’s view of a business system.

13.5.2.2.6. E = Environment: All organisations operate within the constraints imposed by their environment. PESTLE can be used to identify the main external factors.

13.6. Busines activity models

13.6.1. Creating a business activity model

13.6.1.1. A conceptual model of what we would expect to see to fulfil a particular stakeholder perspective.

13.6.1.2. The business analyst to think about the activities that each stakeholder’s perspective implies.

13.6.1.3. A BAM shows what the organisation should be doing, as opposed to a business process model which explores how it does these things.

13.6.2. Types of activities – Plan, Enable, Do, Monitor, Control

13.6.2.1. DOING activities that are at the heart of the model. These are derived from the transformation of CATWOE and reflect the organisation’s principal business activities.

13.6.2.2. ENABLING activities are next added. These lead into the doing activities on the model and acquire or replenish the resources needed to carry them out.

13.6.2.3. PLANNING activities. We are interested in the planning required within this business system (which will support the strategy execution). Planning activities also include setting targets, such as KPIs.

13.6.2.4. MONITORING activities, the actual evaluation of the performance is done.

13.6.2.5. CONTROL activities may be required to institute the necessary remedial actions, if the monitoring activities reveal that performance is not what was expected in the plans.

13.6.3. Developing a consensus model

13.6.3.1. Initially, there will be one BAM for each distinct perspective.

13.6.3.2. At a later point, these are examined in order to identify where there is agreement or conflict between the BAMs.

13.6.3.3. Ultimately, the aim is to combine them and, in discussion with the stakeholders, achieve a consensus BAM.

14. Modelling Business Processes

14.1. The business processes are the means by which an organisation carries out the internal operations and delivers its products and services to its customers.

14.2. There are many reasons for creating business process models:

14.2.1. To understand how the existing process works.

14.2.2. To explain what they do and how their task relates to the others working on the process.

14.2.3. To help ensure consistency of approach.

14.2.4. To identify the problems and weaknesses of an existing business process

14.3. Organisational context

14.3.1. It is useful to examine the organisational context in which the business processes take place.

14.3.2. The traditional view of a business is based on the specialist functional areas.

14.3.3. Functional view of an organisation

14.3.3.1. Very useful for the internal management and staff to see how the organisation is structured and where they fit within it.

14.3.3.2. There are some limitations with this view:

14.3.3.2.1. It is predominantly internally oriented, concentrating on the structure of the organisation and the internal reporting lines,

14.3.3.2.2. it defines the formal structure, ignoring the unofficial communication and cooperation between staff.

14.3.3.2.3. This view is also ‘static’ as it does not show what the business does over time.

14.3.3.3. Thinking of the organisation as separate, autonomous departments may erect barriers and create operational difficulties

14.4. An alternative view of an organisation

14.4.1. Paul Harmon (2007) developed the organisation model that provides an alternative view of an organisation,

14.4.2. The model is often developed in two stages: firstly, the external factors that influence the organisation are considered and then the internal business process is analysed.

14.4.3. There are four areas that define the context in which the organisation operates.

14.4.3.1. The suppliers of the resources required by the business processes.

14.4.3.2. The beneficiaries from the organisation.

14.4.3.3. The competitors operating within the same industry or business domain.

14.4.3.4. The generic factors that may affect the organisation such as changing regulation, economics or green issues.

14.4.4. Analysing the external context encourages the business analyst to think carefully about the context for the organisation.

14.5. The organisational view of business processes

14.5.1. An organisational business process map is formed from a high-level set of activities carried out in order to deliver benefit or value to the customers.

14.5.2. Process maps show sets of related processes, and their interactions, in a single diagram.

14.5.3. It is useful to begin by considering:

14.5.3.1. the core operation at the heart of the entire process, for example, taking bookings or selling goods;

14.5.3.2. the processes that provide input to the core process, for example, scheduling events or making goods;

14.5.3.3. the processes concerned with delivering products or services to the customer, for example, issuing event confirmation or delivering goods;

14.5.3.4. any sales, marketing or customer service processes.

14.5.4. The overview process map is extremely useful to identify the boundaries of each process by showing where the process begins and where it ends.

14.5.5. An alternative approach is the Michael Porter’s value chain to take a look at the products and services and consider what processes are required to deliver them.

14.5.6. We can use the concept of a value chain to develop high-level process maps for the organisation.

14.6. Value propositions

14.6.1. A value proposition is a definition of an organisation’s product or service that will demonstrate to customers that we understand and can satisfy their needs.

14.6.2. The proposition attributes cover three areas:

14.6.2.1. product/service attributes that define the product itself;

14.6.2.2. customer relationship aspects;

14.6.2.3. image and reputation aspects.

14.6.3. Elements of a value proposition:

14.6.3.1. Product / Service

14.6.3.1.1. Functionality – or what the product does.

14.6.3.1.2. Price – what we charge for the product.

14.6.3.1.3. Quality – or how well the product performs.

14.6.3.1.4. Choice – do we simply provide a standard product or can it be tailored to the specific needs of the customer?

14.6.3.1.5. Availability or timing – for example how quickly can we respond to customer requests

14.6.3.2. Image

14.6.3.2.1. The image may be that of the product, built up through extensive advertising and supported by the product attributes in order to generate customer loyalty.

14.6.3.3. Relationship

14.6.3.3.1. The customer relationship aspects will influence how a customer feels about purchasing from the organisation.

14.6.4. An organisation can differentiate itself in three ways:

14.6.4.1. by being the most efficient;

14.6.4.1.1. Efficiency here means high volumes, low costs (and hence, low prices).

14.6.4.2. by having the best products;

14.6.4.2.1. Best products implies high quality but also innovation and the ability to introduce new products before the competition.

14.6.4.3. by providing the best customer service.

14.6.4.3.1. High levels of customer service rely on flexibility which allows the product to be adaptable to the exact needs of the customer.

14.7. Business Process models

14.7.1. A business process is triggered by a business event and includes five key components:

14.7.1.1. the tasks that make up the process

14.7.1.2. the decision points

14.7.1.3. the process flow, the decision points

14.7.1.4. the actors that carry out the tasks

14.7.1.5. the outcome of the business process.

14.7.2. Unfortunately, there is no universally agreed set of terms in business process modelling. We have adopted the following convention:

14.7.2.1. ‘Process’

14.7.2.1.1. refers to an entire set of activities that start with a triggering event and end with some output being delivered.

14.7.2.2. ‘Task’

14.7.2.2.1. refers to an individual activity within the overall process; these are usually carried out by an actor at a single point in time.

14.7.2.3. ‘Step’

14.7.2.3.1. refers to the activities carried out within an individual task.

14.7.3. Business events

14.7.3.1. External – these business events originate from outside the organisation or the business system under consideration.

14.7.3.2. Internal – these business events originate within the business system and typically involve business managers making decisions.

14.7.3.3. Time-based – these business events occur at a regular point in time.

14.7.4. Developing the business process model

14.7.4.1. Two of the most popular are the UML activity diagram technique and the Business Process Model and Notation (BPMN).

14.7.4.2. Often called ‘swimlane diagrams’ because the ‘swimlanes’ showing all of the tasks performed by a defined ‘actor’,

14.7.4.3. The swimlane diagramming technique includes the following elements:

14.7.4.3.1. the overall layout;

14.7.4.3.2. the symbols used;

14.7.4.3.3. the sequencing of the symbols.

14.7.4.4. Actors may be individual people, a group of people or an organisation, or may be an IT system.

14.7.4.4.1. where they get their input information from;

14.7.4.4.2. in general terms, what they do with it;

14.7.4.4.3. where they forward it after they have completed their work.

14.7.4.5. The tasks carried out by each actor are shown in a separate band or ‘swimlane’ and arrows are used to show the flow of the work between the different swimlanes.

14.7.4.5.1. The trigger or business event that initiates the task.

14.7.4.5.2. Inputs to the task. This may include the trigger.

14.7.4.5.3. Outputs from the task.

14.7.4.5.4. Costs relevant to this particular task.

14.7.4.5.5. Measures and standards applicable to the task.

14.7.4.5.6. Detailed breakdown of steps within the task.

14.7.4.5.7. Business rules to be followed in performing the task.

14.7.4.6. Hierarchy of process models

14.7.4.6.1. The set of process models – from organisation-level to swimlane diagram to task analysis.

14.7.4.7. Beginning and ending the process

14.7.4.7.1. It is usual for the swimlane of the process initiator to be at the top of the model.

14.7.4.7.2. The variations between the different approaches determine how much detail is shown in that particular swimlane.

14.7.4.7.3. The end of a process is represented by a bullseye symbol.

14.7.4.7.4. Usually processes have multiple pathways and hence multiple ways in which they can end.

14.8. Analysing the as-is process model

14.8.1. Processes are constantly changing to reflect the different environment in which they operate.

14.8.2. Unfortunately, many of these changes occur in an ad hoc and uncontrolled way.

14.8.3. Identifying problems

14.8.3.1. We need to find out how well the 'as-is' process supports the business.

14.8.3.2. Once we have determined the required performance levels, the next step is to compare them with the actual performance of the existing process.

14.8.3.3. A gap between the actual and required performance levels indicates the need for improvements.

14.8.4. Analysing the hand-offs

14.8.4.1. Where one actor passes the work to another actor.

14.8.4.2. Queues form at hand-offs because the two actors have not synchronised their work.

14.8.4.3. A further cause of delays is where there is inadequate resource capacity to handle the throughput.

14.8.5. Analysing the processing

14.8.5.1. it is important to look for the following possibilities:

14.8.5.1.1. Duplication of work.

14.8.5.1.2. Redundancy.

14.8.5.1.3. Lack of standardisation.

14.8.5.1.4. Incompleteness.

14.8.5.1.5. Inconsistent measurement or control.

14.8.6. Other factors causing inadequate performance of a process

14.8.6.1. The staff working on the process may not have the right skills, training and motivation to produce the desired results.

14.8.6.2. The resources made available to run the process may be insufficient to handle the volume of transactions received.

14.8.6.3. The process may not be managed appropriately.

14.9. Improving business processes (to-be business process)

14.9.1. Business rules

14.9.1.1. Constraints – these are the business rules that have to be applied and restrict how a process or task is performed.

14.9.1.2. Operational guidance – these are the business rules that determine how procedures are conducted within the organisation.

14.9.2. Simplify the process

14.9.2.1. Simplifying a process can be achieved by eliminating unnecessary tasks or hand-offs.

14.9.2.2. The process was first introduced but as a result of changes to the business have now become redundant.

14.9.3. Extend the processing

14.9.3.1. The process may be improved by adding extra tasks to the process, or further steps to a task.

14.9.4. Remove bottlenecks

14.9.4.1. Bottlenecks result when there is a mismatch in the capacities of related tasks.

14.9.5. Change the sequence of tasks

14.9.5.1. ‘As is’ business processes often reveal their origins.

14.9.5.2. Example is the use of computer systems to automate the flow through a process, removing the need for human intervention.

14.9.6. Redefine process boundary

14.9.6.1. The boundary of an ‘as is’ process may be redefined in order to improve the process.

14.9.7. Automate the processing

14.9.7.1. Automation means using computer software to perform tasks rather than carrying them out manually

14.9.7.2. There is a range of automated solutions that are relevant to process improvement initiatives:

14.9.7.2.1. Bespoke IT development.

14.9.7.2.2. Packaged applications.

14.9.7.2.3. Workflow management systems.

14.9.7.2.4. Straight through processing (STP).

14.9.8. Redesign the process

14.9.8.1. The approach could be described as the incremental improvement of an existing process. Hence the sequential steps:

14.9.8.1.1. develop the ‘as is’ model;

14.9.8.1.2. analyse the ‘as is’ process and define its problems;

14.9.8.1.3. identify potential improvements;

14.9.8.1.4. document the ‘to be’ process model.

14.9.8.2. There are some situations, however, where we cannot adopt this approach.

14.9.8.3. we will be able to model the new ‘to be’ process as a black box, defining:

14.9.8.3.1. the expected outcomes from the process;

14.9.8.3.2. the events or triggers that the process will need to react to.

14.9.9. Process Measurement

14.9.9.1. When we are designing an improved business process, we must define not only what the process does but also how well that processing is to be carried out.

14.9.9.2. The importance of measurement is illustrated by the oft-quoted statement ‘You can only manage what you can measure.’

14.9.9.3. Internal measures

14.9.9.3.1. Internal measures are often derived from organisational objectives, critical success factors and key performance indicators.

14.9.9.3.2. These measures are usually defined at an organisational level, cascaded down to departmental level and then further to the operational level.

14.9.9.3.3. The operational measures should support the higher-level measures, right up to the organisational level.

14.9.9.4. External measures

14.9.9.4.1. The other aspect to performance measurement is concerned with what the customer expects to have delivered.

14.9.9.4.2. There are three major areas to think about:

14.9.9.5. Process and task measures

14.9.9.5.1. The performance targets set for a particular process have to align with the expectations of the customers.

14.9.9.5.2. Estimating the timeline for a process is difficult. It will depend on a range of factors including:

14.9.9.6. Performance issues

14.9.9.6.1. Measures and targets need to be chosen with care especially when managers are given incentives to achieve those targets.

14.9.9.6.2. Targets will change the way that people behave – that is what they are designed to do.

14.9.9.6.3. It is possible that the behaviour could be inappropriate if we have not thought the implications of the targets.

15. Defining the Solution

15.1. Gap analysis

15.1.1. Gap analysis requires the business analyst to explore the differences between a current state and a desired future state.

15.1.2. A Business Activity Model (BAM) provides a conceptual overview of a desired future business system, showing ‘what’ activities would be needed to fulfil a stakeholder perspective.

15.1.3. At a more specific level, gap analysis may be used to examine any of the following areas:

15.1.3.1. the ‘as is’ and ‘to be’ business process models;

15.1.3.2. the competencies held by an individual and those required for a particular role;

15.1.3.3. the IT system requirements and the features offered by an off-the-shelf software package.

15.1.4. Identifying areas of concern

15.1.4.1. The activities on the BAM should be inspected and categorised in order to identify those requiring further attention.

15.1.4.2. Three categories may be used for the activities:

15.1.4.2.1. operating satisfactorily – no immediate action;

15.1.4.2.2. some issues to be addressed – action required;

15.1.4.2.3. not in place – urgent consideration.

15.1.5. Framework for gap analysis (elements of POPIT model)

15.1.5.1. The initial investigation focuses on modelling the processes or defining the requirements but this can lead to the change proposals being limited or failing to address the real problems. The holistic approach adopted by business analysts helps to avoid such issues.

15.1.5.2. The POPIT model can help considerably with this investigation as it provides a framework and aide-memoire that helps ensure that the analysis considers all of the required elements.

15.1.5.2.1. Processes

15.1.5.2.2. Information and technology

15.1.5.2.3. Organisation

15.1.5.2.4. People

15.1.6. Formulating options

15.2. Introduction to Business Architecture

15.2.1. Any proposed business change must align with the business architecture.

15.2.2. The business architecture helps to provide increased visibility and effectiveness.

15.3. Definition of Business Architecture

15.3.1. A blueprint of the enterprise that provides a common understanding of the organisation that can be used to align strategic objectives and tactical demands.

15.3.2. A robust business architecture results in the following:

15.3.2.1. the strategy drives changes to the business architecture;

15.3.2.2. the business architecture informs and refines the strategy;

15.3.2.3. the business architecture translates the strategy for execution;

15.3.2.4. the strategy execution enables and generates improvement to the overall business architecture.

15.3.3. A business architecture has three primary objectives:

15.3.3.1. To promote organisational health

15.3.3.2. To help fulfil unrealised opportunities

15.3.3.3. To aid organisational performance in a competitive market place

15.3.4. In addition, it is worth keeping in mind the following key points about a business architecture:

15.3.4.1. The scope of a business architecture is the scope of the business.

15.3.4.2. A business architecture is not prescriptive.

15.3.4.3. A business architecture is developed iteratively.

15.3.4.4. A business architecture is reusable across business units and businesses.

15.3.4.5. A business architecture is not about the deliverables.

15.4. Structure of a business architecture

15.4.1. For example, the artefacts of a business architecture might document any of the following:

15.4.1.1. capabilities;

15.4.1.2. values;

15.4.1.3. information;

15.4.1.4. products;

15.4.1.5. suppliers and partners;

15.4.1.6. motivations;

15.4.1.7. business units;

15.4.1.8. policies.

15.4.2. Evolving best practice has shown that the key elements of a business architecture represent the following areas:

15.4.2.1. business motivations;

15.4.2.2. business capabilities;

15.4.2.3. value streams

15.4.2.4. organisational business units;

15.4.2.5. information concepts.

15.5. Business Architecture techniques

15.5.1. Definition of a capability model

15.5.1.1. Capability models represent, at a high level, what the organisation needs to be able to do in order to deliver value to customers.

15.5.1.2. A full business capability model usually investigates and models the whole organisation across a number of business strata (layers).

15.5.1.3. The main strata (layers) found on a typical business capability model would be:

15.5.1.3.1. strategic or direction setting;

15.5.1.3.2. core or customer facing;

15.5.1.3.3. supporting.

15.5.1.4. It should be noted that the following rules apply when producing a business capability model:

15.5.1.4.1. capabilities should be defined in business terms;

15.5.1.4.2. capabilities should be named as nouns not verbs;

15.5.1.4.3. capabilities are static (value streams show movement);

15.5.1.4.4. capabilities should be unique across the entire capability model;

15.5.1.4.5. capabilities are enabled via value streams.

15.5.1.5. Organisations that document and maintain business capabilities can change more quickly and effectively than those that do not.

15.5.2. Definition of a value stream

15.5.2.1. Value streams are used to identify, map and analyse the value exchanged between an organisation and various stakeholders (internal and external) that interact with it.

15.5.2.2. They focus on the delivery of value and may not reflect the way the work is done in practice.

15.5.2.3. The value stream shows the main sequential stages which add value to the customer. It should be noted that the value stream considers all the stages needed.

15.5.2.4. It is common for each of the individual stages within a value stream, such as the one shown here, to be enabled by a number of organisational capabilities identified from the previously defined Business Capability Model.

15.5.2.5. When producing a value stream, it is worth noting some key guiding principles. Value streams should:

15.5.2.5.1. be stakeholder focused;

15.5.2.5.2. take a holistic view;

15.5.2.5.3. be customer centric;

15.5.2.5.4. facilitate further decomposition;

15.5.2.5.5. help identify which business capabilities help achieve stakeholder value.