bcs foundation certificate in business change · welcome to qa’s foundation certificate in...
TRANSCRIPT
BCS Foundation Certificate in Business Change
BCS Foundation Certificate in Business Change FCBC v3.7
1
Contents How to use this workbook ........................................................................ 3
Foundation Certificate in Business Change Introduction ........................ 5
1. Business Change Principles .............................................................. 11 2. Business and IT Alignment ................................................................ 43
3. Business Improvement Definition ...................................................... 74
4. Business Change Design ................................................................ 116
5. Business Change Implementation ................................................... 159
6. Benefits Management and Realisation ............................................ 174 Answers to Post Tests ......................................................................... 193
Index .................................................................................................... 195
2
How to use this workbook
Activity
Alongside this icon you will find details of the group/ individual activity or a point for everyone to discuss.
Definition
Where a word with a very specific definition (or one that could be described as jargon) is introduced this will highlight that a definition is provided.
Exam tips
This icon indicates an examinable technique or will highlight information that you may find useful in the exam.
Expansion materials
This manual contains examinable materials. The QA++ symbol contains further information. Skip over these during class. They are not needed for the examination.
Glossary
Link to a definition that can be found in the glossary.
Helpful hint
This icon guides you to tips or hints that will help you avoid the standard pitfalls that await the unwary practitioner or to show you how you might increase your effectiveness or efficiency in practising what you have learnt.
3
Important idea or concept
Generally this icon is used to draw your attention to ideas that you need to understand by this point in the course. Let your trainer know if you do not understand or see the relevance of this idea or concept.
Key point
This icon is used to indicate something that practitioners in this field should know. It is likely to be one of the major things to remember from the course, so check you do understand these key points.
Reference material
When we have only touched briefly on a topic this icon highlights where to look for additional information on the subject. It may also be used to draw your attention to International or National Standards or Web addresses that have interesting collections of information.
Reinforcement
From time to time, there will be places within the course where it is useful for you to reinforce your understanding. This might be in the form of a question to ponder or a short end-of-chapter test.
Useful tool
This icon indicates a technique that will help you put what you have learnt into action.
Warning
This icon is used to point out important information that may affect you and your use of the product or service in question.
4
Foundation Certificate in Business Change Introduction Welcome to QA’s Foundation Certificate in Business Change course.
During the next three days, you will learn the skills, techniques and knowledge required to pass the BCS examination in this subject.
Full details of the syllabus can be found on the BCS website at www.bcs.org
Course administration
Before we begin the course, your instructor needs to take you through a number of administrative points as shown below.
5
BCS course objectives
BCS specify that holders of the Foundation Certificate in Business Change should be able to:
• Appreciate the principles, process and roles involved in business change
• Understand the importance of aligning the organisation with external and internal influences and the approaches to do this
• Understand the business analysis approach and techniques used to identify business improvements
• Design the inter-related elements required to implement successful business change
• Understand the processes that should be employed to deploy business change effectively
• Manage the classification, review and realisation of benefits
Course topics
In order to achieve the objectives, the syllabus covers the following topics:
• Business change principles • Business and IT alignment • Business improvement definition • Business change design • Business change implementation • Benefits management and realisation
6
Foundation Certificate in Business Change Exam format
• 40 Multiple choice questions
• 4 potential answers
Multiple choice
• Exam paper and answer sheet only
• Questions weighted on syllabus topic
Closed book
• 40 marks available• 65% to pass = 26 correct answers
• BCS administered• PHOTO ID required
60 minutes' writing time
7
BCS International Business Analysis Diploma
Core Knowledge-based Specialism
Practitioner Specialism
Business Analysis Practice
Commercial Awareness
Modelling Business Processes
Requirements Engineering
Foundation Certificate in IS Project Management
Systems Modelling Techniques
Foundation Certificate in Business Analysis
Systems Development Essentials
Foundation Certificate in Business Change
Benefits Management & Business Acceptance
Both of the above plus
1 of the above and 1 of the above
8
BCS oral examination
• Can be booked once all required written exams have been passed
• Must be taken within 12 months of written notification of passing the final exam
An Oral Examination is required to complete the
Solution Development or
Business Analysis Diploma
• Questions range over the latest BCS syllabus for the modules taken. Each Oral has its own syllabus, and so may cover topics in addition to the written modules. http://certifications.bcs.org
2 BCS Examiners, 40/50 minute
interview
• Review the 'Candidate Guidelines' available from the BCS covering the Oral Examinations:
Review BCS’ ‘Candidate Guidelines’
•Attendance at a Preparation Workshop covering all the relevant syllabus topics from an 'oral examination' perspective is recommended, but not mandatory
Oral Preparation Workshops
9
About the Materials
The Course Manual All of the notes and everything you need is contained in this course book.
There are also post tests which will help you to test your knowledge at the end of each section.
The Exercise Workbook You will also have an a4 exercise workbook containing all of the exercises, the glossary that is referred to, sample exam and answers, as well as further reading references.
The Syllabus (pre-course reading) You will have been sent the syllabus as pre-course reading which also contains some useful information. Please let your instructor know if you haven’t received this document.
10
1. Business Change Principles
Objective To appreciate the principles, process and roles involved in business change.
Topics
In this section of the course we will cover:
• The distinction between IT projects, pure business projects and IT-enabled business change projects
• The distinction between IT as a driver and IT as an enabler • The degrees of business change • The distinction between improving business operations and
improving business information • IT as a core competence and the implications for the
outsourcing business model • The business change life cycle • The stages in the business change life cycle • The identification, analysis and management of stakeholders • The business, project and external stakeholders • The roles and responsibilities of key stakeholders
11
The Distinction between IT Projects, Pure Business Projects and IT-Enabled Business Change Projects A Project is an organisation structure by which a team performs related activities within a defined scope and constraints, in order to produce required deliverables and achieve a specific objective. FCBC Glossary.
IT-Driven Projects Some projects will be entirely IT-driven and will mainly require IT staff, the impact of the change will be within the IT area. Such projects are needed:
• When the hardware requires change or upgrade • Where the infrastructure is requiring modification. Which could
be driven by external factors such as the hardware manufacturer.
• The business should not be adversely affected by these actions.
Pure Business Change Projects Other projects will not be driven by IT changes and may be restricted to business projects. For example
• Re-arranging the physical environment would not involve IT; other areas of the business would be involved, such as facilities or the HR department.
There may be minimal IT involvement but IT is not the driving force behind the need for change. These changes still need to be co-ordinated and managed, therefore they are still a project.
IT-Enabled Business Change Projects IT-Enabled Business Change: the use of information technology as a basis for improving the operation of an organisation. FCBC Glossary.
An IT-enabled business change is driven by the need to take advantage of an opportunity that has arisen because of changing IT functionality. For example the introduction of the internet has enabled
12
businesses to change the way they work to reach a much wider audience.
IT continues to change and businesses are well aware that to keep up they must consider what IT can do for them.
The business challenge is to work with IT and adopt what is appropriate for the business to achieve their overall goals as determined by their vision and strategy.
Activity 1 – Role of IT in Business Change
13
The Distinction between IT as a Driver and IT as an Enabler How do we distinguish between IT as a driving force and IT as an enabling force?
IT as an Enabler
• IT is often fundamental to running Business as Usual (BaU)
o IT is an essential component for almost all businesses and has continually evolved since its introduction
o IT enables business to continue to run their ‘Business as usual’ in an efficient manner.
• IT is often fundamental to bringing about improvements
o IT has enabled many businesses to grow and expand their operations by providing automation or better Management Information, enabling companies to focus on their core activities by providing the information on which to make decisions and improve their efficiency and effectiveness.
IT as a Driver
• IT has also driven business to make changes, providing new possibilities and even suggesting new business models
• Whole new businesses have been created but the reverse has also happened with some businesses facing extinction as demand for a product dwindles or moves to an alternative.
IT can be both a Driver and an Enabler for business change depending on how organisations choose to take advantage of advances in IT to improve their operations and provide business benefit.
14
The Degrees of Business Change In trying to classify the degree of change a useful model is one suggested by Venkatraman, who recognised that some means of defining a ‘small’ change as opposed to a ‘large’ change was needed.
Level Type Change Target Example
1 Evolutionary Localised Exploitation
Deployment of individual systems, e.g. sales support system
2 Evolutionary Internal Integration
Use of IT across a business process. Replacement of existing system by an additional ERP module
3 Revolutionary Business Process Re-design
Re-engineer a part of the business e.g. Order fulfillment
4 Revolutionary Business Network Re-design
Change in supplier contracts
5 Revolutionary Business Scope Re-definition
Enter a new marketplace
Change may range from a small incremental enhancement, building on what is there already, to a major re-engineering programme.
Changing the scope of the business, including entering a new marketplace, is the most demanding level of change according to Venkatraman.
15
__________________________________________________
BPI vs BPR In Problem-solving, you can work forward from the existing situation (Business Process Improvement - BPI) or backward from the desired objective (Business Process Reengineering - BPR).
BPI is building on what is there already whereas BPR works backward from the desired objective.
When working forward (BPI), you analyse the current system, work out what its problems are and then fix them.
One major problem with doing that is that we may waste resources fixing a problem in a process or task that isn’t needed at all!
The alternative (BPR) is to ignore where we are at the moment and go directly to the desired result.
One major problem with doing that is that the change required is likely to be greater, giving rise to greater risk, for example.
These are the extremes – any given change is somewhere along a continuum between these extremes. Usually, we have choices about whereabouts on the continuum to pitch the change effort.
_________________________________________________________
16
The Distinction between Improving Business Operations and Improving Business Information Consider the following with regards to improving operations:
• How do we know we need to improve? • How do we know if we have improved? • How do we know what we know? • How do we know what we don’t know!
Feedback is essential for any business system to monitor its performance and recognise where improvements are needed.
Why Measure and Analyse Information? A business needs to measure and analyse information to:
• Inform management decisions on running the business • Understand how well the business is performing • Identify problems or opportunities • Recognise improvements before and after a change • Understand the quality of a process • Identify whether an organisation is hitting its targets
17
___________________________________________________
Six Sigma Six Sigma seeks to improve the quality of process outputs by identifying and removing the causes of defects (errors) and minimising variability in manufacturing and business processes that are critical to achieving customer satisfaction.6 Sigma has a five step approach (DMAIC) based on analysis of the current situation to Define the problem, often by means of gathering numeric data about the situation, Measuring the resulting data, Analysing what it says, implementing an Improvement and Controlling the resulting change. There are 6 levels of process quality, 6 being the highest, most defect free level.
It is heavily based on statistical analysis and therefore measuring processes and analysing the resultant information is key to identifying where defects are occurring. _________________________________________________________
18
IT as a Core Competence and the Implications for the Outsourcing Business Model A core competence is the notion that a certain section of the total business activity constitutes the core part of the business. It is where value is really created for the customer.
IT as a Core Competence A question that can be asked: is IT a core competence for an organisation?
For example, the core competency of a hairdresser is their skill in dressing hair, not their IT based appointment system.
Core Competence is a business capability that provides customer benefits and is hard for competitors to imitate. FCBC Glossary.
• IT is a key factor in the success of many businesses by providing strategic support and operational support
A lot of the services provided by an IT solution do not necessarily have to be developed and maintained by an internal department. Commercial Off The Shelf (COTS) products offer businesses certain capabilities they require without the need for internal development or maintenance, reducing the effort and cost involved for the business. E.g. A hairdresser can easily purchase an appointment system and a stock management system without having to engage the skills of an IT professional.
• Organisations need varying degrees of IT capability
Businesses however, cannot always replicate their processes by purchasing an ‘off-the-shelf’ solution.
• Is IT a core competence? • Is IT critical to the success of your business? • Is it your secret ingredient and therefore not something
you would want to share with other companies? • Does it provide competitive advantage? • Can it be difficult for the competition to imitate?
For some businesses IT will be so critical, even strategic, that most IT activities will be maintained in-house.
19
For others, where IT is not a core competence and plays a more routine supporting role, outsourcing might be considered.
Outsourcing Considerations Outsourcing is the use of external suppliers to provide services in place of internal functions or departments. FCBC Glossary.
Some reasons for considering outsourcing are:
• To reduce and control operating costs • To improve company focus on your core business • To free up resources for other projects
• Perhaps using the outsource company for specific systems or activities
• To gain access to world-class capabilities • Perhaps in an area where your internal staff have had
limited exposure to develop certain skills. This notion was very popular with outsourcing of testing
• Where resources are not available internally • Outsourcing would be a means of getting work done
sooner rather than waiting for the limited resources to be available
There are potentially major benefits, but outsourcing is not a short term fix and there may be major risks to be considered, such as:
• The need for contracts which can be inflexible, leading to a rise in costs
• The loss of control of core competency, bearing in mind that one should rarely, if ever, give your core knowledge to any outside company
• Detrimental effects on business operations, outsourcing is not only used for supplying software but can also be offered to provide the whole IT service
20
The Business Change Lifecycle
Mnemonic ADDIR
Over the last few years many organisations have recognised that IT projects are not the answer to their changing business needs; what they need are business change programmes, which may incorporate IT changes. With these programmes there is the need for skills and roles to enable the successful delivery of business change.
The early part of the lifecycle is concerned with the analysis of the organisation and its business needs, in order to determine more effective and efficient ways of working.
Later activities are about change design and development, business acceptance testing and, following implementation, benefits review and realisation.
Extensive analysis is required throughout the lifecycle and the nature of this work is clearly within the role of the business analyst.
21
The Stages in the Business Change Life Cycle
Alignment
Strategy links the organisation to its external environment. As the environment changes the organisation must adapt.
In order to determine where it is going, the organisation needs to know exactly where it stands, then determine where it wants to go, and how it will get there. The resulting output is called the “strategic plan.”
While strategic planning may be used to effectively plot a company’s longer-term direction, one cannot use it to reliably forecast how the market will evolve and what issues will surface in the immediate future. Therefore, strategic innovation and tinkering with the “strategic plan” have to be a cornerstone strategy for an organisation to survive the turbulent business climate.
22
Definition
The definition phase is about defining the elements that will support the change. This includes starting to build a Business Needs Log or high level Requirements List.
The steps shown are the first four included in the change process plan developed by John Kotter of the Harvard Business School in 1996.
1. Organisations and the people in them need to be convinced that a change is necessary
2. From the stakeholder analysis identify a group of individuals who have significant influence derived from position, experience and vision
3. The vision is a ‘pull’ factor that gives us a destination and the strategy for getting there
4. The vision needs to be communicated repeatedly so that people know why we need to change and what the implications of the change are.
One very important output from any business change activity is the Business Case, it is the heart of the business change and should be a constant reminder of what is hoped for and how this will be achieved.
Establish a sense of urgency
Form a powerful guiding coalition
Create a vision
Communicate that vision
23
Business Case: A document that describes the findings from a business analysis study and presents a recommended course of action for senior management to consider. It would normally include; an introduction, management summary, description of the current situation, options considered, analysis of costs and benefits, impact assessment, risk assessment, recommendations, plus appendices that provide detailed supporting information. FCBC Glossary.
Design
The Design phase is all about creating successful changes to the business system.
The notion of a programme is now considered. Major change will generally require a range of skills as many areas of the business are affected, the change may cover people, processes, the organisation structure and technology, an holistic approach to business change.
Design
Business processes
IT application
Job definitions
Organisation structure
Management responsibilites
Tests for all changes
24
Implementation
The deployment of the business changes includes acquiring and deploying the solution, ensuring acceptance and reviewing the change.
Throughout this stage the change team has a major influence on how well the implementation goes ahead. We need to ensure that the changes are delivered in a professional manner. Involving key staff can help to ensure that the message gets to all relevant staff so that they are prepared for the activities as they happen. Learning as we go along and adapting the plan as appropriate will be important, as will ensuring that all the staff is trained. We will need to deal with practical issues as they arise.
Involve key staff
Learn and adapt plan
Train / coach staff
Deal with issues as they arise
25
Realisation
Once the solution has moved into the real world, we have to reassure ourselves and the stakeholders that the changes implemented have been successful (or not!) and have delivered the degree of benefit originally claimed for them.
Pro
ject Change
implemented appropriately?Post implementation review
Bus
ines
s Benefits achievedBenefits review
Cha
nge
spon
sor Will the change
be sustained?Can the change be adopted elsewhere?
26
The Identification, Analysis and Management of Stakeholders What is a Stakeholder?
Stakeholder: An individual, group of individuals or organisation with an interest in the change. Categories of stakeholder include customers, employees, managers, partners, regulators, owners, suppliers and contractors. FCBC Glossary.
An alternative definition of a stakeholder:
Stakeholders are those who have an interest in, or may be affected by, the issue under consideration. They may be internal to an organisation or operate externally to the organisation
Stakeholder identification begins as early as possible in the definition phase of the business change lifecycle. Missing stakeholders or not including the right people is often cited as a cause for project failure.
Stakeholder Management in the Project Lifecycle
Successful engagement with stakeholders translates directly to risk reduction on the project. The success of the change depends on gaining the stakeholders’ commitment and buy-in.
Stakeholder Identification
Where do we find stakeholders?
• Hierarchical Nomination - Sponsor & Programme Manager will be able to advise key stakeholders who need to be involved
27
• Background Research - Feasibility studies, PID’s, TOR’s, Standard lists etc. may identify stakeholders within or outside the area under consideration
• Rich Picture - A snapshot of the current situation which help us to identify a high level view of the process, the stakeholders and their concerns
• RACI/RASCI chart – A useful tool which shows all the stakeholders who are Responsible, Accountable, Supportive/Supported, Consulted and Informed for each project output
• Stakeholder Wheel – 8 stakeholder types can be considered
The Stakeholder Wheel
The following eight stakeholder types are shown on the “wheel”:
• Partners • Other organisations that work with ours to deliver
complementary or supplementary products and services
• Suppliers • External organisations that provide products or services
to our organisation • Regulators
• External bodies that set and enforce regulations to which our organisation is subject
28
• Employees • Operational staff who deliver our products or services
• Managers • Senior and middle management who run the
organisation, monitor progress and deliver results required by the owners
• Owners • Depending on which sector our organisation is in, could
include shareholders, trustees or government ministers • Competitors
• Other organisations that deliver their version of products or services to the same target customers
• Customers • Recipients of our organisation’s products or services
Once they have been identified, the stakeholders expectations and needs need to be considered and agreed.
It is important to note that this is not an exhaustive list, there may be other stakeholders involved in your own projects.
Stakeholder Power/Interest Analysis Stakeholders may be analysed and categorised using the power/interest grid.
Stakeholder Analysis: The analysis of the levels of power and interest of a stakeholder in order to assess the weight that should be attached to their issues. This technique provides a means of categorising stakeholders in order to identify the most appropriate stakeholder management approach. FCBC Glossary.
Individual stakeholders or groups of stakeholders are plotted on the grid using the two axis: level of power either to block or advance the project; level of interest in what you are doing.
Once the stakeholders have been plotted, the grid is overlaid to identify management or communication approaches.
29
Stakeholder grid showing management strategies
This grid is useful for initial mapping and for continued reference as the programme progresses and peoples’ views change. How a stakeholder feels at the start of the programme may not be how they feel as the details become clearer.
30
Stakeholder Attitudes
You now need to know more about your key stakeholders. You need to know how they are likely to feel about and react to your project.
If they are not likely to be positive, what will win them around to support your project? If this is not possible, how will you manage their opposition?
• Will actively work for the success of the project
Champion
• Generally in favour but will not actively promote the project
Supporter
• Has expressed no opinion for or against
Neutral
• Not in favour but not actively opposed
Critic
• Will actively work to disrupt or impede the project
Opponent
• Will obstruct progress, maybe for reasons outside the project
Blocker
31
Managing Stakeholders The analysis of stakeholders’ power, interest and attitude enable the creation of a stakeholder plan defining how the project team will communicate and work with each individual stakeholder o stakeholder group.
Stakeholder Management: the definition of the most appropriate means to be adopted in order to engage with different categories of stakeholder. The approach to each stakeholder will be different depending on their level of interest in the project and the amount of power or influence they wield to further or obstruct it. FCBC Glossary.
32
Communication Plans
• Appropriate communications must be thought out for each stakeholder or stakeholder group
• Project Manager, Business Analyst & Business Change Manager should work this out together
• A small number of stakeholders will need to be involved as members of the project team – High Power, High Interest
• Some stakeholders will need to be consulted • Experts on the rules (SMEs) • Their permission for change must often be sought
• Others will only need to be kept informed • Typically a numerous group • Use of presentations, seminars, webinars, roadshows,
newsletters etc
Case Study Exercise 1 – Stakeholders
33
The Business, Project and External Stakeholders
The Roles and Responsibilities of Key Stakeholders Role of Business Sponsor also known as Senior Responsible Owner or Officer (SRO)
• Commissions the change and holds executive authority and budget accountability
• Represents the executive viewpoint
34
• Provides stewardship: ensures the business case is sound, that the funding required is a good use of the company’s resources
• Provides leadership: inspires, creates and communicates the vision
• Examines and evaluates options • Ensures resources are available • Makes the benefits happen and is accountable for the outcomes
See Business Sponsor in FCBC Glossary.
Role of Business Change Manager (BCM)
• Focused on the business implications of the change for the business processes, the people and the organisation structure (POP)
• Ensures business readiness • The “Sponsor’s representative on earth” • Manages the changes needed in the business
• Helps define benefits on behalf of the sponsor, determines feasibility, assesses progress, suggests improvements and alternatives
• Link between programme management and business operations
• Linked into the change management function • Focused on communications with all stakeholders
Role of the Business Actor and Subject Matter Experts (SMEs)
• Carry out the work within the context of business processes, in the affected areas of the business
• SMEs provide intimate business knowledge, feedback, assist with scenario building and test scenarios
• Vital that they are involved especially in respect of solving the ‘tacit knowledge’ problem
• Supports Business Acceptance Testing, by providing knowledge of the end-to-end business process to ensure that there are no gaps in the solution
See Business Actor / Business User in FCBC Glossary.
35
Role of Programme Manager /Project Manager
• Programme: • A change programme delivers an improved strategic
capability through a set of interdependent projects • Programme manager: planning, monitoring and
controlling a suite of projects • Project:
• A management environment that is created for the purpose of delivering one or more business products according to a specified Business Case
• Project Manager: runs the project. Needs a combination of hard and soft skills
See Programme Manager / Project Manager in FCBC Glossary.
Role of Business Analyst (BA)
• Seek out and engage with key stakeholders • Gather, analyse, specify, validate requirements
• Investigate problem areas • Propose change options
• Model as-is and to-be business processes • Identify relevant IT support
• Liaise between IT suppliers/developers and the business community
• Identify test scenarios and liaise with the test team • Analyse and advise on data changes
Business Analysis: An internal consultancy specialism that has the responsibility for investigating business situations, identifying options for improving business systems and bridging the needs of business with the use of IT. FCBC Glossary.
Role of IT Specialists
• Scope the IT contribution, in conjunction with the business analyst
• May need to consider strategic planning, enterprise architecture and IT innovation needs
Examples of IT (Application, Data and Service Management) Specialists
36
• Systems Analyst – responsible for a particular project • Solution Architect – often assigned to a project to support
technical issues • Technical Architect – some companies will have ‘experts’ on
technical issues, these people will be consulted and may even have sign off responsibility
• Developer – Responsible for creating the new IT system to meet the requirements therefore concerned with their feasibility and testability
• Tester - responsible for the testing of any IT system
Examples of Data Specialists
• Data Modeller – knowledgeable about data modelling approaches
• Data Steward – representative from the business who advises on specific data usage or definitions
• Database administrator (DBA) – IT specialist who supports the physical representation of data
Service Management
• Responsible for the day to day operation of the installed solution in the operational environment
• Will need to understand the end solution and accept responsibility for its maintenance
• Clear SLA’s and support arrangements will need to be agreed, documented and communicated
The Skills Framework for the Information Age (SFIA) has been developed by the BCS, with input from industry experts, to identify and define industry standard job roles within an IT function and provide a benchmark for skill levels. www.sfia.org.uk
Suppliers
• May have specific requirements to input to the project • Will be interested in how interactions are going to change and
the impact upon them
37
Customers
• Will want to understand how any changes will impact them • May need to be consulted for their opinions on the change • May have specific requirements to input to the project
Regulators
• Will need to be satisfied that any changes still adhere to regulations
• Legislation may form requirements the project needs to meet
38
Post Test 1
To reinforce the materials we have just covered, try out the following questions which are in the style of the exam questions.
Answers can be found on page 193.
1. IT-enabled business change is concerned with:
A. Making business changes to match the capabilities of the purchased software packages
B. Ensuring that all functions within the organisation use Information Technology
C. Using new technology developments as quickly as possible D. Improving business performance through the application of
Information Technology
2. Which of the following ideally represents the role of technology in an IT-enabled enterprise?
A. IT is an enabler for achieving the strategy of an organisation B. IT is one of the external drivers of business strategy C. IT is both a driver and an enabler of business strategy D. IT is neither a driver nor an enabler of business strategy
3. Which of the following provides the most complete definition of a stakeholder?
A. Someone who has an interest in the business change project
B. A competitor organisation C. An individual member of staff who will use the new IT
system D. Anyone who holds a senior management position in the
organisation
4. Which of the following roles has the responsibility for planning a business change project?
A. Programme manager B. Business analyst C. Management consultant D. Business actor
39
5. What is the primary role of a business sponsor in an IT-enabled change programme?
A. To manage the delivery of the outputs against the plan B. To appoint the teams including selection of suppliers C. To ensure that customers understand the change
programme D. To be accountable for the outcomes
6. A Business Actor must be able to:
A. Manage the achievement of the business case B. Analyse and model business requirements C. Represent the interests of the entire group of business
users D. Provide information about the business domain
7. The Senior Responsible Owner/Project Owner (SRO/PO) is the
individual responsible for ensuring that a project or programme of change meets its objectives and delivers the projected benefits. Which of the following two managerial roles are accountable to the SRO/PO?
A. Programme Manager and Business Change Manager B. Business Sponsor and Project Manager C. Programme Manager and Programme Office Manager D. IT Manager and Business Change Manager
8. Which of the following most closely represents the relationship that
IT could have with business change initiatives?
A. Driver and Enabler B. Supplier and Provider C. Driver and Supplier D. Provider and Enabler
9. Which of the following Stages in business change will not normally
be included within the project lifecycle?
A. Define B. Design C. Deliver Benefits D. Implement
40
10. Where would you expect the change Sponsor to be located on a Power/Interest Grid?
A. Low/Low B. Low/High C. High/Low D. High/High
11. Which one of the following would not normally be considered to be
part of the Business Analyst role?
A. Gathering Requirements B. Identifying Stakeholders C. Ensuring Resources are available for the Project D. Liaising with IT Suppliers
12. Which of the following is not normally an example of an internal
stakeholder?
A. Sponsor B. Business Analyst C. IT Consultant D. Business Actor
41
End of chapter notes
42
2. Business and IT Alignment
Objective
To understand the importance of aligning the organisation with external and internal influences and the approaches used to do this.
Topics
In this section of the course we will cover:
• Aligning the organisation with the external environment, the vision, mission, objectives, strategy and tactics and the Enterprise Architecture
• The external and internal business environments for organisations
• Organisational cultures • National cultures • The implications of culture for business change projects • Corporate and IT governance and the relevance to benefits
management and risk management • Elements of an Enterprise Architecture
43
Aligning the Organisation with the External Environment
The business needs to know where it is and where it wants to be – business strategy development.
The business must align its Internal and External environments
This is then an input into the alignment of the organisation with the external business environment to identify opportunities and threats, as well as identifying what strengths and weaknesses exist within the companies own resources.
Business Strategy: A strategy describes the medium to long-term approach defined for an organisation in order to achieve the organisational objectives. FCBC Glossary. Also see Strategy.
Knowing what it has to build on in terms of internal capability and also the technical infrastructure is essential. There is no point in the business considering a new venture if it does not have the capability to support it.
The Business must align its IT with the business mission and goals
44
Resources cover human, technical, financial and physical; various things can limit the overall expectations of the company, and it is for that reason that the idea of knowing what we have – an Enterprise Architecture is considered a valuable asset.
The External and Internal Business Environments for Organisations: The Business Domain Any organisation can be affected by various external, as well as internal, factors. We can use a number of industry standard approaches to try to understand the external and internal world.
Strategic Analysis: the application of techniques in order to analyse the pressures within an organisation’s external business environment and the level of internal organisational capability to respond to these pressures. FCBC Glossary.
External Business Environment: the business environment that is external to the organisation and is the source of forces that may impact
45
the organisation. Types of forces may include the introduction of new laws, social trends or competitor actions. FCBC Glossary.
Techniques to analyse these external forces are the PESTLE Analysis and Porter’s Five Forces.
External Analysis - PESTLE PESTLE is a tool that can help organisations develop strategies by examining the external business environment in which they operate. The external environment comprises those factors and trends outside the organisation which might have an influence upon it and its future. Many external factors can have an effect on an organisation; from changes in legislation to the entry of new competition into a market.
The six factors for PESTLE, are:
The complexity of the external environment faced by different organisations is likely to vary greatly.
A global corporation will face many influences, some changing from country to country such as consumer legislation, while others like technological changes are intrinsically more international.
In contrast, the influences faced by a village shop are likely to be more limited in range and variety, such as the number of local customers and their buying habits, though no less critical to the success of the business.
46
The main problem with these external PESTLE factors is that they are continuously changing. PESTLE analysis should include a thorough analysis of what is affecting the organisation now, and what is likely to affect it in the future.
The result of a PESTLE analysis is usually a list of positive and negative factors that are likely to affect a business. However, by themselves they mean very little. It is important to bear in mind that PESTLE analysis requires careful application of results.
The six PESTLE factors may be applied to the whole of the organisation, or to specific business areas, or to specific parts of business areas, in order to contemplate the likely effects.
PESTLE Example
Take an oil exploration and Production Company as an example, what external factors might affect it?
• Political Willingness to exploit natural resources
• Economic The oil price
• Socio-cultural Contradictory attitudes to burning fossil fuels.
• Technological Drilling technology
• Legal Health and safety legislation
• Environmental Global warming
47
External Analysis - Porter’s 5 Forces
The Porter’s 5 Forces model is used to analyse a business domain or industry, developed by Michael Porter in 1979, to determine the attractiveness of a market.
There are four forces, which combine with other variables to influence a fifth force; the level of competition or rivalry in an industry:
• the bargaining power of customers • the bargaining power of suppliers • the threat of new entrants • the threat of substitute products
This framework can help to identify strategic targets; for example if suppliers are powerful, then our strategy should be to reduce this power, for example by acquiring the suppliers’ involved (vertical integration).
What could be done about strategic threats from the other forces?
The results of a PESTLE and Porter’s 5-forces analyses may be used to populate the opportunities and threats elements of the SWOT.
48
See PESTLE and Porter’s 5 forces in FCBC Glossary. Having completed our external environment analysis, we now consider the organisation’s capability to respond to the opportunities and threats identified using internal environment analysis techniques.
Internal Business Environment: the internal capability of the organisation that affects its ability to respond to external environment forces. Techniques such as MOST analysis or the Resource Audit may be used to analyse the capability of the internal business environment. FCBC Glossary.
Activity 2 – PESTLE Analysis
49
Goal Alignment - MOST / VMOST Analysis VMOST provides a framework for the examination of the direction and focus of an organisation. The results of a VMOST analysis can be used to populate the strengths and weaknesses elements of the SWOT.
It is a way of representing a business plan and may be both an input to the strategic planning process and an output from it.
The Vision describes the future of the organisation and a clear Mission drives the organisation forward. From the Mission, the Objectives, Strategies and Tactics will be developed based on internal and external environment analysis. See FCBC Glossary.
This is one of the key tools used in exploring corporate strategy and Strategic Planning.
This process should work from top to bottom and vice versa.
• From the top, clarifying the mission drives the objectives which create strategic options which forces tactical actions to be taken
• From the bottom, every action at tactical level should help to make the strategies work, all strategies should help to achieve the objectives, and all the objectives should take the business towards the mission
•The overall vision of the future of the organisationVision
•The high level direction set for the organisationMission
•The defined goals to be achieved by the organisationObjectives
•The means of achieving the goals over the medium to long term
Strategies
•The detailed means of delivering the strategy over the short term
Tactics
50
Mission The commercial mission statement consists of 3 essential components:
• Key Market – who is your target client/customer? • Contribution – what product or service do you produce for that
client? • Distinction – what makes your product or service unique so that
the client would choose you?
The Mission is a statement defining why the organisation was created. It defines the Scope or Domain of the organisation, for example: Insurance Companies don’t brew beer!
Attributes of Good Objectives
Objectives should be SMART:
Specific: An observable action, behaviour or achievement is described which is also linked to a rate, number, percentage or frequency. ‘Answer the phone quickly’ can be said to be a precise description of behaviour, but there is no rate, number, percentage or frequency linked to it.If we state; ‘Answer the phone within 3 rings’ a rate has been added and the behaviour is now much more specific.
Measurable: A system, method or procedure has to exist which allows the tracking and recording of the behaviour or action upon which the objective is focussed. Setting an objective that requires phone calls to be answered in three rings is fine, provided a system exists which measures whether this is actually being achieved.
Achievable: The objectives that are set need to be capable of being reached - there is a likelihood of success (but that does not necessarily mean easy or simple).
Relevant: Avoid the temptation of defining a goal just because it fits nicely to the previous three criteria; it must take us towards our mission.
Time-framed: In the objective somewhere there has to be a date (Day/Month/Year) for when the task has to be started (if it’s ongoing) and/or completed (if it’s short term or project related).
51
SMART: a mnemonic used to ensure that objectives are clearly defined in that they are specific, measurable, achievable, relevant and time-framed. FCBC Glossary.
Note that there will only be a single mission but this may lead to several objectives, each of which may have several strategies and which, in turn, may have several tactics. Think of an upside-down tree structure.
Internal Resource Audit A resource audit starts the internal analysis process by identifying what capabilities we have that we can build on and where there are areas of internal weakness that we need to overcome. Physical, Financial and Human are all tangible resources; Know-how and especially Reputation are less so.
Note that there may be negative aspects under these headings too.
This will feed directly into the Strengths and Weaknesses in our SWOT analysis.
• Buildings, plant, equipment, land
Physical
• Capital and credit available
Financial
• Staff and their expertise
Human
• Including patents and trade marks owned
Know-how
• Brand and goodwill
Reputation
52
Resource Audits are identifying business capabilities where future products/services will come from, enabling the business to have an agile response to future opportunities.
Business Capability: the capacity of an organisation to provide services to customers. FCBC Glossary.
SWOT Analysis SWOT Analysis: a technique used to summarise the external pressures facing an organisation and the internal capability the organisation has to respond to those pressures. The mnemonic stands for Strengths, Weaknesses, Opportunities and Threats. SWOT analysis is used during strategy analysis. FCBC Glossary.
Note that strengths and weaknesses may already have been identified by Resource Audit and VMOST analysis. External analysis techniques mentioned earlier, PESTLE and Porter’s 5 Forces identify opportunities and threats to be input into the SWOT.
SWOT
Carrying out an analysis using the SWOT framework helps focus your activities into areas where you are strong and where the greatest
53
opportunities lie. To carry out a SWOT Analysis, write down answers to the following questions. Where appropriate, use similar questions:
Strengths: What are your advantages? What do you do well? What relevant resources do you have? What do other people see as your strengths?
In looking at your strengths, think about them in relation to your competitors - for example, if all your competitors provide high quality products, then a high quality production process is not a strength in the market, it is a necessity.
Weaknesses: What could you improve? What do you do badly? What should you avoid?
Opportunities: Where are the good opportunities facing you? What are the interesting trends you are aware of? Useful opportunities can come from such things as: - changes in technology and markets on both a broad and narrow scale, - changes in government policy related to your field, - changes in social patterns, population profiles or lifestyle changes for example.
A useful approach to looking at opportunities is to look at your strengths and ask yourself whether these open up any opportunities. Alternatively, look at your weaknesses and ask yourself whether you could open up opportunities by eliminating them.
Threats: What obstacles do you face? What is your competition doing? Are the required specifications for your job, products or services changing? Is changing technology threatening your position? Do you have bad debt or cash-flow problems? Could any of your weaknesses seriously threaten your business?
Impact of IT
• IT may be one of the required core competencies of the business; e.g.
• Supports the products/services directly • Supports the relationship with customers and others
• IT may be a Strength or a Weakness; e.g. • Effective, efficient IT is a Strength
54
• Legacy systems may be impeding change, so IT may be seen as a Weakness
• IT may be an Opportunity or a Threat; e.g. • Opportunity, if the business can leverage the
technology • Threat, if use of IT attracts virus attacks or security
issues
55
Organisational Cultures
What is organisational culture? And why does it matter?
• While not always easy to capture or define, culture is an observable, powerful force in any organisation
• Made up of its members’ shared values, beliefs, symbols, and behaviours; culture guides individual decisions and actions at the unconscious level
• As a result, it can have a potent effect on a company’s well-being and success.
Organisational Culture is often commonly defined as the attitudes, values, beliefs, norms and customs which distinguish an organisation from others (Carnall, 2007)
Organisational Culture: The values, behaviours and symbols adopted by an organisation. FCBC Glossary.
Organisational Culture - Handy
Culture is ‘the way things are done around here’; different organisations will be run differently.
Charles Handy popularised the following model identifying four types of organisational culture:
• Power Culture: where power is centralised with the most senior person in the organisation. In extreme cases a power culture is a dictatorship, but it does not have to be
• Role Culture: where a bureaucracy exists with highly structured and well-documented procedures, e.g. UK civil service
• Task Culture: where work is done through empowerment, flexibility and teams. Often associated with matrix or project-based organisations, teamwork is crucial
• Person Culture: focus is on individuals who are likely to be connected by strong values, influence is shared and the power base is usually expert, that is, people do what they are good at and are listened to for their expertise. Consultants, architects practises and some universities are all examples of this type of culture
56
Culture is difficult to change and should be suited to the nature of the organisation.
International Cultures - Hofstede Hofstede researched the cultures of different nations, initially identifying four dimensions and later adding a fifth. The dimensions are measured along a spectrum from high to low.
• Power Distance: a society with high power distance is one in which the members expect that power is distributed unequally and are less likely to question the person at the top
• Individualism: a society with high individualism is one in which the ties between individuals are loose. People are expected to look after themselves and their family. The opposite is collectivism
• Masculinity: a society with high masculinity is one where values such as assertiveness and competitiveness are prevalent and women are less likely to be treated as equals. The opposite is high femininity cultures which place more value on relationships and quality of life
• Uncertainty Avoidance: a society may have a low tolerance for uncertainty and ambiguity
• Long-term vs. Short-term Orientation: a society may value perseverance and have a long-term orientation or alternatively may have a short-term orientation. Hofstede added this fifth dimension later
Countries are rated on a scale of 1 to 120 for each of the 5 dimensions.
_________________________________________________________
In Cultures and Organisations: Software of the Mind (2010) Hofstede added a sixth dimension, indulgence versus self-restraint.
_________________________________________________________
The Impact of Cultural Change
• Taking a holistic approach to a typical project:- • Around 20% of the focus should be on IT.
57
• Given that technology is now pretty much a commodity. It still takes effort but, with the right people and appropriate technology, the desired outcomes (in IT terms at least) should be achievable.
• The other 80% should involve looking deeper • Understanding the cultural implications of change and,
importantly, addressing working practices and business processes to ensure change is not only immediate but is also sustainable.
The Implications of Culture for Business Change Projects National culture is carried over into the organisations where people work and so affects the organisations’ culture.
Cultures, working practices and motivational factors are important areas for any business to consider when implementing change.
Understanding the cultural implications of change and, importantly addressing the working practices and business processes to ensure change is sustainable and accepted is vital to implementing successful change initiatives.
This requires not only an awareness of an organisations culture but also an holistic approach to business change.
58
Taking an Holistic Approach
Mnemonic POPIT
See Holistic Approach in FCBC Glossary.
59
Corporate and IT Governance and the Relevance to Benefits Management and Risk Management The culture of the organisation influences the rules of management. As IT is so critical to the success of most organisations the rules relating to IT need to be established, this is called IT Governance (ITG).
IT Governance is the accountability framework that ensures management responsibility for the two key goals: ensuring that the investments in IT generate business value and balancing the risks associated with IT investment against the return delivered. FCBC Glossary.
IT Governance must be in harmony with the goals of Corporate Governance as IT is an expensive resource and the investments made must be justified to support the overall business goals. Procedures and roles to manage the costs need to be established and controlled.
Risks in IT also need to be managed and balanced against any reward that might accrue. Again, control and management is needed, with audits conducted at appropriate times.
There are a number of industry standards that businesses can use to ensure its IT resources achieves its goals, the choice of which ones to adopt is a business decision.
_________________________________________________________
CobiT 5 and ISO 38500 provide standards for IT governance.
_________________________________________________________
Some IT Governance Instruments
• Organisation Structure; clear roles, responsibilities and accountabilities for decisions affecting:
• Programmes and projects • Developments in Applications, Data, Technology • Provision of IT Services
• Committees and Steering Groups; starting at the Executive level
60
• Broker agreement on deployment of resources • Share knowledge across the business • Concentrate on adding value • Identify and control risk
• Maintaining an Enterprise Architecture
Governance and Management
Governance is not management, it is setting the rules. How these rules will be implemented is up to the management team.
Good IT Governance can enhance the business operations, create value and support strategy but at its worst bad IT Governance can impede the business operations, destroy value and lead the business into severe difficulties.
Involvement of Senior Management
Ensuring the involvement of senior management is essential as decisions taken can have far reaching implications for the growth and stability of any company.
Senior Management engagement and commitment is vital and helps specify what the role of IT is supposed to be in the business strategy. Business and IT must work together to get the best value from the Business investments in IT.
61
Risk All business change involves risk. There should be a process in place to identify, document and manage risk.
Risk: a problem situation that may arise with regard to a project or business situation. Potential risks are identified for each option in a business case, and following assessment, suitable countermeasures are identified. FCBC Glossary.
Risk Identification
There are generic risks which surrounding people, process and technology as well as specific risks associated with a proposed change.
Risk identification is usually a project team effort as people from different areas contribute to what could possibly go ‘wrong‘.
Risk Management: the identification, assessment, monitoring and control of significant risks during the development, design and implementation of IT systems. FCBC Glossary.
• Assess the risks for probability and impact • Probability – ask yourself is this expected to happen? A
wet day in the summer in England would probably be a YES
• Impact – what difference would it make? Someone’s wedding is a once in a lifetime event so it would be a disaster if we couldn’t take photographs outside
• Identify appropriate mitigation actions for each risk • It depends on the severity of the risk, you can reduce
the impact sometimes, you can also reduce the probability but whatever action you decide to take will need to be assessed, planned, costed and considered
• In our example; we could consider mitigating the risk of it raining or being miserable by planning for indoor photographs or erecting a marquee
• Allocate an owner • The person who will be responsible for carrying out the
risk mitigation actions. If you decide to hire a marquee for the wedding it’s the person who arranges this
• Monitor and control until they are no longer a risk
62
• When risk action is taken, it is still necessary to keep an eye on the mitigating actions
• If the risk action is to tolerate the risk it still needs to be reviewed to ensure the impact has not increased
Various mechanisms are used to record the risk assessment. Some organisations use a heat map, others develop their own questionnaire focussed on their business area, but whatever is used to record the initial view of risks it is only the beginning of risk management and not the end.
Risk Evaluation – Heat Map
Low probability
Medium probability
High probability
High impact AMBER RED RED
Medium impact
GREEN AMBER RED
Low impact GREEN GREEN AMBER
A risk heat map is used to plot risks against two axis: level of impact and level of probability. Appropriate risk management strategies may be considered depending on the cell of the heat map to which the risk is allocated. For example: low probability, low impact risks would fall into the ‘green’ cell so the strategy may be to accept the risk; a high impact, high probability risk would fall into a ‘red’ cell and so would require action to manage the risk.
Risk Responses, Risk Mitigation
Risk mitigation actions are:
• Transfer: perhaps it is possible to transfer the risk, say through insurance or sharing with 3rd parties. Remember though that ownership of the risk does not change, so although someone else may be working with you the risk still needs to be monitored and managed
• Accept: used in the green area of the map, and if costly to address; create a contingency plan
63
• Reduce: try to reduce either probability and/or impact – this is called containment
• Avoid: possibly by avoiding the use of new technology until it is proven. Management for high impact/high probability risks
Mnemonic: TARA to remember risk responses.
Contingency is the action you would take if the risk occurs and becomes an issue.
64
Elements of an Enterprise Architecture (EA) The business change cycle recognises the importance of the alignment of business and IT strategy in the initial phase.
An Enterprise Architecture (EA) is a target model for the organisation covering both business components (motivation, processes and information) and technology components (applications and infrastructure)
See Enterprise Architecture in FCBC Glossary.
EA is about designing an IS/IT capability, a roadmap into the future to support business strategy, one of the express aims of an EA is to try to ensure that business and IT goals are properly aligned and that they stay that way.
IT Governance is making sure that the roadmap is followed.
There are a number of enterprise architecture standards that could be followed. The two most well used are The Zachman framework and The Open Group Architecture Framework (TOGAF).
65
The Zachman Framework of Enterprise Architecture
Zachman recognised that in order to understand and successfully specify IS/IT architecture it is necessary to understand the business context – i.e. The Business Architecture. The second row of Zachman is the Business Model.
The third row is the System Model which includes applications software and data, while the fourth row is the Technology Model.
Rows 2, 3 and 4 together are what we now known collectively as the concern of Enterprise Architecture.
Row 5 is the solutions row i.e. what products realise the architecture and row 6 is ‘Business as Usual’, the deployed solutions.
The columns of this matrix represent different architectural elements that are exposed in the various Views (rows).
66
The 6 columns respond to the 5WH acronym (what, how, where, who, when, why).
• What: Focus on data • How: Focus on function and process • Where: Focus on locations and networks (assets) • Who: Focus on people and organisation • When: Focus on time, timing, triggers and events • Why: Motivation; aims, goals and objectives
The column order is not significant but the row order is, as each row provides a foundation or starting point for subsequent rows.
Zachman is a static model of architecture – there is no explicit suggestion of how to develop and modify architectures, though a top-down flow is usually regarded as implicit.
Different people within an organisation will be involved in gathering the information needed to populate all the various diagrams and models required. The following table identifies these interests.
It is a major undertaking for any organisation to decide to develop an enterprise architecture.
67
TOGAF – The Open Group Architecture Framework
The TOGAF Metamodel considers the same information as the Zachman model but the presentation is different, it includes:
• The Business Architecture - defines the business strategy, governance, organisation, and key business processes
• The Data Architecture - describes the structure of an organisation's logical and physical data assets and data management resources
• The Application Architecture - provides a blueprint for the individual applications to be deployed, their interactions, and their relationships to the core business processes of the organisation
• The Technology Architecture - describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards and so on
TOGAF also includes a model of change and development called the Architecture Development Method (ADM), affectionately known as the ‘crop circle’ and this model is used to demonstrate how you would develop enterprise architecture.
68
TOGAF’s Architecture Development Method
Firstly, a demand has to be identified; the ‘Preliminary’ bubble means we need to build an architecture based on the central requirements. Once this has been agreed the model is alphabetically addressed and at each bubble there is a requirement which is met by a model. The models must be built according to the required overall organisational objectives.
It is not a small task for an organisation and as you can see bubble H is about change management.
Can you imagine how easy or difficult it is to keep this up to date with all the changes happening in an organisation?
69
Post Test 2
To reinforce the materials we have just covered, try out the following questions which are in the style of the exam questions.
Answers can be found on page 193.
1. Which of the following are represented in the two E’s of PESTLE
a. External factors b. Environment factors c. Economic factors d. External events A. b and d B. b and c C. a and d D. a and c
2. Businesses are motivated by different targets at different levels
within the organisation. Which of the following best represents a top down sequential description of these motivations?
A. Mission, objective, strategy B. Strategy, mission, objective C. Mission, strategy, objective D. Objective, mission, strategy
3. What is not an example of a risk arising from an IT-enabled
business change?
A. Poor response time resulting from moving to on-line order entry
B. Limited training and use of new compliance system C. Disaster recovery plan fails due to changes in phone
numbers D. Poor Information flows hinder redesigned processes
70
4. Which of the following reasons best explains why it is strategically important to evaluate organisational capability?
A. To identify where there are job roles that need to be filled B. To scope the ability to respond to external opportunities C. To allocate responsibility for business change programmes D. To define the hardware resources for an IT-enabled project
5. ‘Business Strategy’ may be best described as the result of attempts
at which one of the following alignments?
A. Internal and External Environments B. Internal Environment and IT C. IT and the External Environment D. Business Processes and IT
6. In a SWOT analysis which one of the following represents the internal focus?
A. Strengths and Opportunities B. Opportunities and Threats C. Strengths and Weaknesses D. Threats and Weaknesses
7. Which one of the following pairs of techniques can help identify important external factors that may influence strategy?
A. MOST and 5 Forces B. SWOT and PESTLE C. Value Chain and SWOT D. PESTLE and 5 Forces
8. Raising ‘Barriers to Entry’ is a suitable response to which one of the following of Porter’s 5 forces?
A. Threat of Substitute products and services B. Threat of New Entrants C. Power of Suppliers D. Intensity of Competition
71
9. Which of the following is the most accurate description of ‘IT Governance’?
A. Telling personnel how to use their IT in support of their business tasks
B. Setting up roles, responsibilities and accountabilities for decisions affecting the use of IT in the business
C. Sanctioning personnel for breaches of IT usage policy D. Taking decisions on suitable IT acquisitions and the
deployment of IT assets throughout the business
10. Which one of the following is an example of an Enterprise Architecture Framework?
A. Porter’s 5 Forces B. TOGAF C. Value Chain D. CobiT
11. Which one of the following combinations are all valid risk counter measures?
a. Accept b. Denial c. Ignore d. Insure e. Transfer f. Avoid
A. b and c B. b and d C. d and b D. e and f
72
End of chapter notes
73
3. Business Improvement Definition
Objective
To understand the business analysis approach and techniques used to identify business improvements.
Topics In this section of the course we will cover:
• Investigating the business situation: rationale and techniques
• Holistic approach and systems thinking
• Gap analysis: purpose and approach
• Business requirements elicitation and analysis
• The contents of the business case
• Stakeholder responsibilities and the business case
• The business case lifecycle
• Programme definition
74
Investigating the Business Situation: Rationale and Techniques Assuming there is...
• Broad stakeholder agreement on the size of the strategic opportunity
• An initial appreciation of the scope of what has to be done to achieve the benefits
Then...
• The gap between as-is and to-be must be identified, along with options for closing the gap
• Scope needs refinement and the implications for change in the affected areas of the business must be understood by the stakeholders.
• A Business Case is needed to describe and guide the change process, based on the chosen option.
The business analyst needs to investigate with stakeholders what is required for the change.
Main Elicitation Techniques
There are many requirements elicitation techniques available to the analyst. We will consider:
• Background research • Interviews • Workshops • Observation
Option: A possible solution to a business problem. Options are evaluated in a business case in terms of their costs, benefits, risks and impacts. FCBC Glossary.
75
The information and knowledge that the analyst is seeking is of two basic types:
Explicit Knowledge: the knowledge that is foremost in the business user’s minds, and which they can easily articulate. FCBC Glossary.
Tacit Knowledge: Those aspects of business work that a user is unable, or omits, to articulate or explain. This may be due to a failure to recognise that the information is required or to the assumption that the information is already known to the analyst. FCBC Glossary.
The challenge for the Business Analyst is selecting the appropriate investigation techniques to elicit the tacit and explicit knowledge.
_______________________________________________________
Other useful techniques which are not part of the syllabus include:
• Document analysis • Questionnaires • Focus groups • Prototyping • Scenario building • Special Purpose Records • Activity Sampling
_________________________________________________________
What are the Advantages and Disadvantages of Interviews, Workshops and Observation?
76
Background Research There needs to be a starting point to any analysis and gaining an understanding of the business area, the processes carried out, any systems used and potential problems encountered is as good a starting point as any. It is also extremely useful and could provide information not previously known.
This may be achieved through review of project documentation i.e. Business Case, PID, TOR and other assets. Or through combining with other techniques such as Document Analysis to review procedures, organisational structures and user manuals to provide insight.
Interviews A structured discussion between the analyst and a stakeholder to elicit facts and information about the business situation and their role in it. Usually a one-to-one meeting.
• Great for • Rapport-building • Yields important information
• But • Time consuming • Information must be verified • Are the right people interviewed? • Have you asked the right questions?
See Interview in FCBC Glossary.
Interviewing is an excellent elicitation technique and a key analysis skill. The analyst uses the interview as a technique for gathering detailed information from a key stakeholder to understand their viewpoint. The interview is especially useful when trying to understand the business area under investigation in order to understand the problems and elicit the requirements.
Among the advantages of using an interview is that it enables us to build a working relationship with key stakeholders as we are in a confidential, one-on-one setting with them. However, if we were to rely exclusively on interviews it would be very time consuming, and each interview only gives us one stakeholder’s point of view which may need to be confirmed through the use of other techniques.
77
Workshops A workshop is a team-based information gathering and decision making technique designed to accelerate business planning and development. It is an interactive communication technique involving empowered personnel working in one or more sessions run by an independent facilitator to achieve an agreed objective.
Advantages include:
• Several viewpoints are canvassed • Increase speed and productivity. Saves having many interviews • Helps gain consensus and buy-in
Disadvantages include:
• Time-consuming to organise • Requires careful facilitation • Attendees need authority to make decisions
A workshop should be used when decisions are required, to explore ideas and exchange knowledge to solve a business problem. Facilitated workshops are an excellent forum for requirements analysis and negotiation.
The strength of the facilitated workshop technique is that it enables the exchange of information between key individuals and enables them to reach decisions that are mutually acceptable. A workshop provides a forum for exchanging views and achieving consensus decisions in a structured framework across and within areas of the business. Clear deliverables are produced during the workshops enabling all attendees to review decisions taken by the group.
Badly planned and conducted workshops could be a complete waste of everyone’s time. The symptoms of a bad workshop include:
• A vague, ambiguous statement of the objectives • A lack of clear focus and direction • A lack of consensus and commitment to the solutions • Time-wasting • Side discussions, arguments etc.
See Workshop in FCBC Glossary.
78
Observation Watch what people do either by formal agreement or informally by just ‘wandering about’
• Formal observation • Watching specific tasks being performed • Prepare staff to reduce fear
• Protocol analysis • Getting users to do something and describe each step
as they do it • Shadowing
• Following a user for a short period to find out what their job entails
• Ethnographic studies • ‘Fly on the wall’ observation • Extended period
See Observation in FCBC Glossary.
Observation is particularly useful for uncovering tacit information as you see the process being carried out, including any skills required and the environment it has to work within. This can be done in a number of ways. If you are going to carry out observation it is important to get the agreement of those being observed to avoid possible problems.
Advantages include:
• Gain a good understanding of the process, problems, politics etc.
• Helps devise workable, acceptable solutions
Disadvantages include:
• The people being observed can feel unsettled – ‘Big Brother’ • Your presence may impact the process
79
_______________________________________________
There are many useful techniques for requirements elicitation.
_______________________________________________
• Supplements other techniques; best to use completed forms and reports
• Good for limited information from lots of people, can be hard to formulate
• Identifies views of customers or staff
• Working models of solution
• Tells the story of a task, identify exceptions
• Staff record simple data on the job
• Analyst records; use in preference to SPR when accuracy is important
Sampling
80
Holistic Approach and Systems Thinking Successful change requires a holistic approach, we need to think of the business area as a business system.
Various components of the organisation may need changing as well as IT such as:
• Processes and procedures • People, their roles, knowledge and/or skills • Organisation structures, including policies, or governance • Equipment and the physical infrastructure
‘Systems thinking’ is a way of tackling complex changes that require a holistic approach.
Systemic Thinking: An approach that considers a business situation as if it were a system of integrated component systems. FCBC Glossary.
Business System
Systems theory suggests that all systems have certain characteristics:
81
• Every system has a defined purpose and operates within a defined environment
• The environment generates events that the system must respond to
• The appropriate response is created by using internal resources, combining the components present in suitable ways, governed by rules of internal behaviour
• An open adaptive system must have mechanisms for feedback and control.
• For example it must be able to check up on goal achievement and take corrective action if necessary
It is helpful for Business Analysts to think of organisations as if they were open adaptive systems.
Such a view promotes a holistic approach to the change process.
Holistic Approach: The consideration of a business system, the people, processes and organisational areas, in addition to the information and technology used to support the business system. FCBC Glossary.
Business System: A set of business components working together in order to achieve a defined purpose. The components of a system include people, IT systems, processes and equipment. Each component may be a system in its own right. FCBC Glossary.
Notion of a System
• There are ‘hard systems’ that are engineered such as circuit boards, where the system behaviour is predictable and a known output is produced for a given set of inputs
• E.g. mobile phone, computer program.
See IT System in FCBC Glossary.
• Also there are ‘soft systems’, like organisations • When people and groups are involved their behaviour
and output is less predictable, and therefore the system is much ‘messier’ to engineer.
82
Principles of Taking a Systemic View
When thinking of a business in this way we must:
• Acknowledge and confirm the system’s purpose • Understand the environment and context of the system • Identify all major components in the system, actual or required,
and their relationships • Ask ‘Where is change needed? How will relationships be
affected?’
We need to:
• Understand the main events affecting the system and its actual or required behaviour in response to them. Are there any new events to be dealt with?
• Appreciate the system’s capacity to adapt and absorb change • Consider the feasibility of absorbing the degree of change,
without serious loss of performance • Identify feedback and control mechanisms • Ensure appropriate measures of performance are understood,
in place or planned
83
Soft Systems Methodology (SSM) A methodology devised by Professor Peter Checkland and his team at Lancaster University provides an approach to the investigation and analysis of problem situations in ‘soft systems’ such as organisations.
SSM was developed because the human aspects of the change are often more difficult to resolve. This approach uses a number of models to document the people situation and to understand their perspective.
The methodology suggests an approach to problem identification, and differentiates between the ‘real world’ and the world of systems thinking.
The 7 ‘Stages’ of Soft Systems Methodology
SSM begins with an investigation into a real world situation of concern and Checkland proposed we use ‘rich picture’ to document it. The different ’world view’ of each stakeholders is then developed using a CATWOE and formalised as a sentence, known by Checkland as a ‘root definition’, but we prefer the term ‘business perspective’.
From each business perspective a model of the stakeholder’s desired business system is produced, then the differences between these conceptual models are considered and the models are brought together in one consensus model, which represents the desired future system.
84
This model is then compared to real world models, including the rich picture we produced earlier. By carrying out a gap analysis we can identify feasible, desirable changes that need to be made to the existing business system. This leads us to taking action to improve the problem situation, and could involve changes to the People, Organisation, Processes and Technology.
See FCBC glossary for Soft Systems Methodology, Rich Picture, Business Perspective, Root Definition, CATWOE and Business Activity Model.
Rich Pictures
A rich picture is a representation of the business situation which concentrates on the people aspects of the situation and shows concerns and attitudes.
A rich picture allows the business analyst to document whatever is of interest or significance, including the human and cultural aspects as well as key process flows and information usage.
85
There is no single way of drawing a rich picture. An analyst may find different styles useful in different situations. Ideally the rich picture is captured on one page and hence provides a distilled view of all aspects to be considered. This helps the analyst to develop a mental picture of the situation and see how the different aspects relate to each other.
Commonly used symbols are stick-people to represent stakeholders, buildings to represent organisations, arrows to represent flows (of anything) and the crossed swords to represent conflict. In this example, the central element is the pub, so that has been sited centrally and the other elements placed around it.
A rich picture or other model identifies a number of participants and stakeholders in the system.
Differing Business Perspectives
Business perspectives are a way of deriving their individual view on a problem situation: what is their underlying belief about its purpose?
A business perspective is derived for each actor/stakeholder.
A Business Perspective is a view taken by a key stakeholder of what the business system is, so it provides a possible model for a future system. Of course there could be multiple perspectives, and therefore multiple models, and so it is important to fully define each one and, if possible, combine them or at least negotiate on the differences.
86
CATWOE Approach The CATWOE Criteria are the basis of a business perspective and are an approach to identifying stakeholder’s beliefs about the system we are investigating
The approach to take when documenting a stakeholder’s perspective is:
• Understand the worldview of the stakeholder under consideration
• Define the relevant transformation – remember this is what the stakeholder thinks the business system should be doing in relation to fulfilling the requirements of the input and adding value to create an output, not what they want to do to change the business system
• Identify the customer(s) targeted by the transformation • Include all actors in the transformation specifically by title or role • Then consider owner and environment
87
• The beneficiaries (occasionally victims!) of the transformation, the recipient of the outputs (goods or services)
3Customer
• Those responsible for performing the business activities included in the transformation
• May include external business partners, e.g. distribution companies
4Actors
• A short description of the highest level relevant business process (which takes inputs, adds value, and produces an output of value to the customer)
2Transformation
• The stakeholder’s beliefs / perspective of the world within which the organisation operates, that makes the Transformation meaningful
• Also called Weltanschauung
1Worldview
• Those who have authority to change or even stop the activities performed
5Owner
• The conditions / rules under which the business system must operate that are outside the control of the owner, e.g. PESTLE factors recognised by this stakeholder or fixed business policies
6Environment
88
Corner Shop Example CATWOE
An example of the CATWOE for a corner shop, from the perspective of the shopkeeper:
Case Study Exercise 2 – Rich Picture
_________________________________________________________
Once documented, the root definitions are transformed into Business Activity Models (BAM) which will give an overall picture of all the future business activities, and enable a consensus view to be reached across the key stakeholders.
This consensus model is then used to consider where we can identify opportunities for improvement.
Business Activity Models are outside of this syllabus.
_________________________________________________________
89
Gap Analysis Purpose and Approach
Gap Analysis: the comparison of two views of a business system, the current or ‘as is’ view and the ‘desired’ or ‘to be’ view. The aim of gap analysis is to determine where the current situation has problems or ‘gaps’ that need to be resolved. This leads to the identification of actions to improve the situation. The business activity modelling technique may be used to provide an ideal view which can then be compared with a view of the current situation. An alternative approach is to use the business process modelling technique, using ‘as is’ and ‘to be’ process models. FCBC Glossary.
It may not be possible to ‘close the gap’ immediately due to various considerations such as:
• Cost • Timescales • Level of risk • Impact on the organisation culture • People issues
These considerations lead to the idea that options should be offered and considered for discussion by the business.
90
The Need for Options
Within a business case selected options will be fully documented to aid the decision makers.
Options Analysis
• Do nothing option i.e. retain current system • The effects of not taking action should be evaluated
• All other options should respond to the Terms of Reference • They should solve the business problem, at least to
some degree • ‘Do a little’ option
• Quick fix, patch type option • ‘Do a lot’ option
• More radical reform, possibly addressing more issues • Recommended option: the analyst’s considered view
The Process
Process for developing options includes:
• Identify the potential options • Business • Technical
• Shortlist the options by considering feasibility • Business • Technical
91
• Financial • Take the shortlisted options forward to the Business Case
See Business Option and Technical Option in FCBC Glossary.
92
Feasibility of Options
Business
Strategic fit
Market conditions
Timeliness
Physical infrastructure
Organisational fit
Cultural fit
Process compatibility
Competencies
Legality and regulation
Technical
Availability
Reliability
Maintainability
Performance
Security
Technical skills
Compatibility
Novelty
Financial
Budget
Funds available
Borrowing available
Return on investment
Cash flow
Payback period
93
Business Requirements Elicitation and Analysis It is necessary to have some understanding of the requirements for each option at this stage to enable accurate description in the Business Case of the costs, benefits, risks and impacts involved.
A typical diagram used to present the requirements engineering lifecycle is shown here.
We can see from the requirements engineering framework that elicitation and analysis are an iterative cycle. In requirements elicitation the BA is concerned with drawing out the requirements from the stakeholders using a number of the elicitation techniques (considered earlier), including potentially visualising the possibilities and ensuring both Tacit and Explicit knowledge is captured.
During requirements analysis we review the requirements to remove inconsistencies and duplication, organise and prioritise the requirements. Typically we:
• Capture the requirements • Analyse them for completeness, conflict etc. • Walkthrough with the stakeholders • Negotiate compromises • Re-work as necessary • Go round until completion
Requirements elicitation
Requirements analysis
Requirements validation
Requirements documentation containing – Requirements Catalogue + Use Case Diagrams + Use Case Descriptions
Requirements management
94
Business requirements elicitation is the proactive investigation and collection of requirements for a solution required to resolve a business problem or enable a business opportunity. FCBC Glossary.
Requirements Elicitation is an approach to understanding requirements that requires the analyst to be proactive in drawing out the requirements from the business users, and helping them to visualise the possibilities and articulate their requirements. FCBC Glossary.
Requirements Classification
Requirements are related to each other.
• Some general requirements include business constraints and business policies with which the solution must comply. These include:
o Branding o Culture o Legal o Language o Business Continuity
Requirements
Business
General
Technical
Solution
Functional
Non-functional
95
• Technical requirements refer to hardware and software constraints. These include:
o Hardware o Software o Applications o Internet Usage o Interfaces
Business general and technical requirements are elaborated and expanded in the functional and non-functional requirements
• Functional and Non-functional requirements tell us what the system must do and the constraints within which it can operate.
• Functional requirements are generally defined as features the solution must offer and cover data manipulation
• Non-functional requirements are defined as the level of performance provided by the solution in areas such as speed of response, usability, capacity, security, access and availability. I.e. how well the functionality will be provided and will perform.
See FCBC glossary for Requirement, Functional Requirement and Non-functional Requirement.
Requirements validation is an external review of the requirements to ensure that they have been defined to the required level of accuracy and detail, and so can be signed off or ‘base lined’.
Underpinning the elicitation, analysis and validation are the two activities of documentation and management, both on-going throughout the whole requirements lifecycle.
Requirements documentation is exactly what it says, the method for documenting the requirements. What form will this take? It is not uncommon for organisations to have their own standard document which they use or even to use a tool for storing the requirements.
A Requirements Catalogue is an organised set of requirements where each individual requirement is documented using a standard template. FCBC Glossary.
96
The Requirements document may include diagrams to support the requirements catalogue e.g. use case diagrams and use case descriptions.
See FCBC glossary for Use Case, Use Case Description and Use Case Model.
Requirements Management is an essential element of ensuring that the requirements are controlled and protected from unauthorised change.
• It is important that every requirement is uniquely identified and cross-referenced to other deliverables from the development activity, testing artefacts and software products.
• The ability to track changes from a requirement to a piece of code and vice versa is needed.
• Often requirements change during a project and this change needs to be appropriately managed.
• Configuration management is required to enable anyone to track changes that have been made to the requirements and identify by whom, also under what authority.
Requirements management aims to ensure that each requirement is tracked from inception to implementation (or withdrawal) through all of the changes that have been applied to it. FCBC Glossary.
A CASE (Computer Aided Software Engineering) tool offers a secure repository to store all the related documentation and can help with the control and traceability of requirements.
See Computer-Aided Software Engineering (CASE) in FCBC Glossary.
97
The Structure of the Business Case The business case document should be based on a company template; it provides the justification for the change; engages and convinces stakeholders and importantly, asks for decisions on investment.
Suggested content of a business case includes:
• Introduction • Management Summary • Description of current situation • Option considered, including
• Do Nothing option • Analysis of Costs and Benefits • Impact Assessment • Risk Assessment
• Recommendation • Appendices
For each option conduct a cost/benefit, risk and impact analysis.
Cost-Benefit Analysis a technique that involves identifying the initial and ongoing costs and benefits associated with a business change initiative. These costs and benefits are then categorised as tangible and intangible and a financial value calculated for those that are tangible. The financial values are analysed over a forward period in order to assess the potential financial return to the organisation. This analysis may be carried out using standard investment appraisal techniques.
See Payback Calculation, Discounted Cash Flow, Net Present Value and Internal Rate of Return. FCBC Glossary.
98
Tangible Costs and Benefits
Tangible costs and benefits are those for which we have a specific basis for measurement, usually financial. For the benefits we would need to have taken a measurement before the project starts so that we have a basis for comparison.
Tangible costs include one-off costs incurred during the project or at the deployment stage and ongoing costs which accrue over time after the project has completed.
Most costs will be tangible, but we must not overlook the ones it is hard to measure, these are known as intangible costs.
One-off (initial) costs
•New hardware• Infrastructure•Software packages
•Development staff costs
•User staff costs•User training•Redundancy•Relocation•Data clean up / migration
Ongoing costs
•Hardware maintenance
•Software support•Salaries for additional staff
• Increased premises costs
• Increased inventory
• Increased consumables costs
• Increased travel / transport costs
Benefits
•Staff savings•Reduced effort• Improved efficiency
•Faster response•Reduced premises costs
•Reduced inventory•Reduced consumables costs
•Reduced travel / transport costs
•Avoided costs
99
It is also important to assess the intangible benefits an option may deliver, as although these cannot be measured in financial terms they should still be providing value to an organisation.
Intangible Costs and Benefits
See FCBC glossary for Intangible Benefit, Intangible Cost, Tangible Benefit, and Tangible Cost.
•Recruitment and induction•Disruption and short-term loss of productivity
Costs
• Increased job satisfaction
• Improved customer satisfaction
•Better management information
•Greater organisational flexibility
•More creative thinking time
•Improved presentation•Better market image•Improved internal communication
Benefits
100
Cost Benefit Measures
When considering the cost benefit analysis it is important to use standard management accounting techniques which can then offer a comparison between the various options.
The three standard techniques used are:
• Payback Period • Discounted Cashflow (DCF)/Net Present Value (NPV) • Internal Rate of Return (IRR)
The definitions of these techniques are shown later in the course.
Risk Analysis
Different options will have different risk profiles.
• Usually high risk means high benefits • High risk, low benefit options should be discarded
Also organisations and individuals have different risk appetites and risk tolerance
• Risk appetite may vary under changing conditions
For each option the risk analysis considers:
• Risks from changes to BaU which may arise from • Process • People • Technology
• Risks from the change process which may arise from • Time • Cost • Functionality (‘Quality’)
See FCBC Glossary for Risk and Risk Management.
The principle risks of each option should be identified:
• Description cause and impact
101
• Impact assessment quantitative measures • Probability likelihood of occurrence • Countermeasures how to reduce risk and impact? • Ownership responsible for countermeasures
Impact Analysis Impact Analysis: The consideration of the impact a proposed change will have on a business system and the people working within it. FCBC Glossary.
Each option needs to be assessed to ascertain the impact on the wider organisation
• Can the business ‘cope’ with yet more change? • Have they reached saturation point? • What changes do they find ‘acceptable?’
For each option what changes will have to be made? • Organisation structure • Inter-department relations • Working practices • Management style • Recruitment Policy • Appraisal and promotion criteria • Supplier relations
Force Field Analysis is a useful tool that can help identify impacts and in particular resistance to each option.
102
Force Field Analysis: a technique to consider those forces inside and outside the organisation that will support the adoption of a proposal and those that will oppose it. The technique was developed by Kurt Lewin and may be used in evaluating options to change and in change management. FCBC Glossary.
Finally the business case is presented to the business and a decision must be made.
Consideration must be given to:
• Who – Which stakeholders will be involved in reviewing and deciding which option to proceed with
• How – What format will the business case be presented in and how will the review take place
• When – What mechanism will be used to present the information and when is this required to take place
103
Stakeholder Responsibilities and the Business Case Depending on the size and scale of the business change people will be assigned to work with the change team to ensure that the requirements are identified and the changes built. The following, lists some of the key roles that will be involved:
104
The Business Case Lifecycle
The business case is a living document which should be revised as the project proceeds.
• The initial business case is often produced from a feasibility study, where costs and benefits are estimated before major resources are committed
• Following requirements analysis and specification by the business analyst the estimates are updated, and the business case is confirmed
• During solution design more reliable estimates of the development costs are used to update the business case
• Once all the deliverables of the projects have been completed they are ready to be implemented into the live environment and the business case is updated with the actual costs of the development.
o Again there is an opportunity to revisit the business case before deployment of the solution to consider whether the conditions are still appropriate, as the business situation may have changed and it may now not be worth proceeding to implementation
• Finally, the new processes and systems are in use in the live environment, and begin earning the benefits identified in the
105
business case. Once the proposed solution has been in operation for a while there should be a review to determine whether the predicted business benefits have been realised
• Between each of the stages of the lifecycle there are “decision gates”, indicated by the dashed lines. Here the project should pass certain tests before being allowed to proceed to the next stage – in this case the tests relate to the business viability of the project
106
Programme Definition Complex change is best organised by creating a programme which is:
• A collection of projects that are directed towards a common goal • Each project is managed as a discrete entity with a project
manager • Projects within a programme are responsible for delivering
outputs which in total deliver the outcomes required by the programme
In major change initiatives there is the need to plan and scope several deliverables in a mixture of business areas
• Generally, projects are identified along functional lines e.g. an HR project, an IT project, a manufacturing project and a delivery project
Programme: a suite of interdependent projects that are required to deliver business change. FCBC Glossary.
Programme Management Definition
• Complex changes may require sub-programmes within programmes
• There is a need to co-ordinate the inter-dependencies of organisation, people, process, information and technology streams.
• A programme is an ideal vehicle for delivering this whenever a major change is required which affects many, or sometimes all, areas of the business.
• Sometimes programmes are split down into projects or ‘work streams’’
Programme Design
• Programme must be planned • Might configure each major deliverable as a work
stream or project • The projects are inter-dependent, so integration is
needed
107
• Several Groups involved in Planning • SRO, Programme Manager, Project Managers,
Business Change Manager • Programme Management methodology is beneficial
• Such as Cabinet Office’s MSP
Programme manager The appointed programme manager runs the programme, supervises the efforts of several project managers and manages the stakeholders, from a high level. There will be several projects which are under the programme; these will each have their own structure and plans driven by a project manager. Each project will focus on the specific outputs that they must produce; the sum total of the outputs will be delivered to the programme manager who is responsible for the outcome of the programme. The programme manager is responsible for:
• Translating high level business plans into projects each supported by their own objectives
• Ensuring the business case and the outcomes are under constant review to ensure they meet the objectives
• Meeting and communicating with the stakeholders as defined in the stakeholder management plan.
• In particular with the sponsor and their representative, the business change manager, sometimes on a daily basis but whenever there are key issues to be resolved.
• Ensuring the profile of the programme within the organisation is appropriate
• Arranging support and clerical assistance from a programme office
See Programme Manager in FCBC Glossary.
Programme sponsor Each programme must have an executive owner; this person must have a clear requirement for the outcome of the programme and owns the business case. The sponsor is accountable for delivering the promised benefits. It should be an appropriately senior person, someone who has the authority to allocate resources whether they are people, funds or facilities. Different titles used are Business Sponsor, Senior Responsible Owner/Officer or Programme Owner, it does not matter what titles is used, the responsibilities are the same.
108
Programme office Some organisations are structured so that they can support programmes of work with a programme office which will provide a lot of the housekeeping and co-ordination activities.
The range of tasks includes:
• Co-ordination of the reports from individual projects and ensuring that they are complete and produced regularly
• Maintaining repositories of documentation • Maintaining stakeholders’ information and contact details • Maintaining the overall programme schedule which is an
accumulation and distillation of the project schedules • Maintaining the programme risk and issues log • Arranging programme meetings • Maintenance of overall issues log
109
Post Test 3
To reinforce the materials we have just covered, try out the following questions which are in the style of the exam questions.
Answers can be found on page 193.
1. It is important to take a systemic view of business change because:
A. IT professionals understand systems and are the main group interested in business change
B. There are often interdependencies and interactions between IT systems
C. Organisations are complex and change to one area is likely to impact upon other areas
D. IT systems are usually the key element in driving business change
2. What is the terminology used to describe the process views that need to be mapped in a process redesign?
A. ‘Current’ and ‘Possible’ B. ‘Today’ and ‘To Be’ C. ‘As Is’ and ‘To Be’ D. ‘As Is’ and ‘Planned’
3. Which of the following roles is responsible for investigating and
documenting business requirements?
A. Programme manager B. Business analyst C. Systems designer D. Business sponsor
4. Which of the following would be identified in a business case as an
intangible cost?
A. Licences for a new software package B. Loss of goodwill C. Hire of a consultant for a study lasting ten days D. Purchase of a new telephone system
110
5. The project sponsor must always be:
A. A senior user of the IT systems affected by the change project
B. The owner of the business case and accountable for its achievement
C. A director of the business functions affected by the change project
D. The head of the IT function working on the change project
6. Which of the following options should always be considered when developing a business case for a new IT system?
A. Outsourcing the IT function B. Developing an IT system in-house C. Redesigning a business process D. Continuing with the current system
7. Taking a ‘holistic’ view of business improvement means:
A. Taking an objective view when examining the range of
possibilities for business changes B. Considering the organisational, process and human
dimensions of change C. Looking for all of the problems with the current business
operations D. Focusing on the ‘soft’ aspects related to any proposed
business changes
8. Which of the following are elements of the Soft Systems Methodology CATWOE technique’?
a. Actors b. Environment c. Trainers d. Owners
A. a, c and d B. b, c and d C. a, b and c D. a, b and d
111
9. Which role in the implementation of business change is responsible for translating high level business plans into formal business cases and that these remain visible throughout?
A. Programme Management B. Quality Management C. Business Change Management D. Supplier Management
10. Which one of the following statements best describes the meaning
of the term ‘system’?
A. An IT Application B. A set of components that collaborate for some purpose C. A procedure for doing something D. The formal documentation of processes
11. Which one of the following most accurately describes what is meant
by the term ‘soft systems’?
A. A piece of applications software B. Network protocols C. People acting together intentionally D. A service business
12. Which one of the following statements most accurately describes
the purpose of a Rich Picture?
A. It forms the basis of a flow chart that describes business processes
B. It shows what sort of data will be required by the new IT system
C. It reflects the people involvement in the situation, their feelings and attitudes
D. It is used to verify stakeholder requirements
13. Which one of the following statements most accurately describes the meaning of the term Root Definition?
A. It is a summary of a relevant system as perceived by a stakeholder
B. It is the Sponsor’s view of the business situation C. It is the Analyst’s view of the business situation D. It is a re-wording of the organisation’s Mission Statement
112
14. Which parts of the CATWOE acronym are essential in forming a
Root Definition?
A. C and A B. T and W C. C and E D. E and C
15. Which one of the following requirements elicitation techniques
would not normally be appropriate for engaging a numerous stakeholder group?
A. Questionnaire B. Survey C. Interview D. Sampling
16. It is considered Best Practice to present options on change to the
Sponsor and Senior Management. Which one of the following is not a valid reason for this practice?
A. It is important that the Sponsor takes ownership for the chosen option
B. Management like to be given choices as it makes them feel important
C. The Business Analyst may not be in possession of all the relevant facts
D. There is almost always more than one way of solving a business problem
113
17. Which of the following topics should always be included in any change option presented to the Sponsor?
a. List of possible risks b. List of estimated costs c. List of IT Suppliers d. List of estimated benefits e. List of possible business strategies A. a, b and c B. b, c and d C. e, d and c D. a, b and d
18. Which one of the following would not usually be considered an
Intangible Benefit of making a change?
A. Improvement in Customer satisfaction B. Improvement in the Company’s margins C. Improvement in the Company’s image D. Improvement in Staff morale
19. Which one of the following would not usually be considered a
Tangible Cost of making a change?
A. Investment in software licences B. Expenses of paying development staff C. Lowering of staff morale D. Interest on loans needed to finance the change
20. Which one of the following phrases best describes the meaning of
the term ‘programme of change’?
A. A Programme of Change is a synonym for a Change Project B. A Programme of Change is the software programming
needed to support the change C. A Programme of Change is a coordinated collection of
change initiatives, designed to implement strategy D. A Programme of Change is a way of controlling Business as
Usual
114
Insert end of chapter notes here End of chapter notes
115
4. Business Change Design
Objective
To design the inter-related elements required to implement successful business change.
Topics
In this section of the course we will understand:
• Aspects of organisational change • Aspects of people change • Aspects of process change • Information analysis and modelling • Aspects of information technology
116
Business Change Design Deliverables The recommendation made to the business, via the business case, outlined what would be delivered if the change was adopted. Authorisation to proceed with making the change will be given, a formal agreement to allocate resources, time and investment to develop and deliver the stated outcomes.
Examples of deliverables from this stage could be designs for:
• A revised organisation structure • A training programme • Revised business processes • An updated information model • A new IT application • Using new technology
The project management framework will determine how this information is presented, often this forms a PID - Project Initiation Document. It is the scoping mechanism for the change team and will determine if a programme or project is needed.
Project Initiation Document: (PID): A document that defines the business context for a project and clarifies the objectives, scope, deliverables, timescale, budget, authorities and available resource. FCBC Glossary.
An holistic approach to change can be considered during the design phase to ensure effective business change, the main areas include:
• Process • Organisational • People • Information • Technology
Case Study Exercise 3 – Business Change Design Deliverables
117
Aspects of Organisational Change There are two aspects to organisational change:
• One is considered to be HARD, the structure of the organisation and performance measures.
• The other is SOFT, ensuring an appropriate culture, improving the skills of the employees and motivating those employees.
An organisation chart shows the different layers representing authority and command, displays some of these HARD aspects.
Organisation Structure: a diagram showing the departments and staff of an organisation. FCBC Glossary.
This formal map shows the command and control structure for an organisation.
The purpose of an organisation structure is to:
• Divide up organisational activities and allocate them to sub-units • Coordinate and control these activities so that they achieve the
aims of the organisation
118
Elements of Structure:
• Hierarchy (Levels in the organisation) • The number of layers of authority that exist • Flat vs Tall hierarchies
• Span-of-control (Supervision of workers) • The number of line staff each manager is responsible
for • Chain of command (Reporting relationships)
• Line relationship • Functional relationship • Staff relationship
• Departmentalisation (Grouping of jobs) • Grouping people and activities based on
Work Skills Expertise Goals Resources used
• Formalisation (Extent of rules) • Business rules • The extent to which these are written down
• Centralisation (Location of decision making) • Decisions over where to hold the decision making
authority
The organisation structure helps identify the Organisation Boundary.
Organisation Boundary: the identification of the scope of an organisation, indicating the activities and units that are within the organisation and clarifying the interactions with the external parties such as partners, suppliers and customers. FCBC Glossary.
We again need to consider organisational culture as we recognise the difficulties of changing working practices and what might be the impact of changing what people consider the ‘normal’ way of working.
119
Aspects of People Change Job and Roles
Defining roles and grouping roles into jobs, defining the skills and competencies of individuals to fill the jobs, managing performance of those individuals and the communication of changes to those affected by the change, are all aspects of people change.
A role is a logical set of responsibilities, typically based on one or more of the following:
• Skills: the basic and specialist knowledge that is needed to perform the tasks required by the organisation. This could be a minimum education standard or a professional qualification
• Authority: the level of authority someone will have in terms of approval or communication. Often financial limits are included here, so that you may have budget authorisation up to a specific amount
• Knowledge: the specific range of knowledge needed, such as a background in IT or contract management, or programme management
• Separation of concerns: where the job has authorisation to do something such as authorise holiday or pay, it is not usual for you to be able to authorise your own holiday, or update your salary
To ensure that a person has enough work to do, a ‘job’ may include several roles as shown below.
Senior Learning
Consultant
Course tutor
Course Director
Senior Learning
Consultant
Course tutor
Skills champion
120
The challenge is to design jobs so that the roles fit together and complement the skills of the individual, whilst adding value to the company.
Each job should have:
• A clear and agreed job description • Current year objectives • A development plan for future growth
Appraisals of an individual’s performance are required on an annual or bi-annual basis. These may be tied in to career development frameworks and reward schemes dependant on the organisation type, size and maturity.
HR must be involved, if the change involves people in any way, as they are experts regarding the legal and policy requirements of your company.
Whenever there are new jobs or changes to existing jobs, to be approved it is usual for HR to provide support for job evaluation and grading, and also to indicate the organisation structure that will support the people.
Work Practice Modelling (WPM)
Work Practice Modelling is the classification of business staff and the definition of user roles in order to provide a basis for job design. FCBC Glossary.
Work Practice Modelling (WPM) is the design of exactly how the work will be carried out. It encompasses making sure that the required IT functions are integrated within the proposed working environment.
There is a danger that new IT functionality will be impractical in the circumstances that the users find themselves in on the ground e.g. an intricate interface may be impractical in the middle of a production line. WPM tries to ensure a mismatch of this kind does not happen.
WPM is not just looking at IT, but also the manual procedures and the general context in which the IT will be used.
Within WPM, Task analysis is performed to reveal what resources are needed to perform which tasks and what volumes are expected. Tasks
121
are then allocated to users via User analysis ensuring the role can be fully justified.
Task Modelling is an important part of WPM.
Task Modelling: A technique for developing a model which describes the human activities and task sequences required by a business system. The task model elaborates the tasks identified by mapping business processes onto specific individuals or workgroups. FCBC Glossary.
Defining Required Skills and Competencies
As always, when appointing people into roles there may be a mismatch between what they can do and what they must do, this competency gap needs to be addressed by means of training or coaching.
The individuals’ development plans should identify what is required for them to be proficient in their jobs.
An example of an industry specific skills framework, for IT, is SFIA.
Competency is a skill or quality an individual needs to perform his or her job effectively. FCBC Glossary.
Managing Performance of Individuals
Managing performance of the workforce is a key role for managers and HR working together. Appropriate policies should be in place to support both the individual and the organisation, and to determine what incentives should be in place, if any.
Reward and incentive schemes can cover:
• Working conditions • Team spirit • Managers support • Financial rewards
People have personal motivations too, so management need to combine personal and business motivations skilfully to provide a ‘win-win’ situation for both the business and the staff member.
122
Staff engagement policies are owned and managed by HR and will ensure that companies are aware of legalities around employment issues, regulations and well-being.
Performance Measurement and Management
Appropriate performance measurement must be designed to:
• Ensure regulatory reporting is satisfied • Encourage desirable behaviour • Get the best out of people • Appraise and improve performance
Salary, bonus and compensation packages encourage appropriate behaviours.
People will tend to behave in work, according to how they are measured, for example through performance targets.
Performance Measurement: measures that enable managers to monitor the results from activities in order to identify successful achievement in line with organisational goals. FCBC Glossary.
Engaging with HR
HR is not the same as Personnel:
• Personnel is typically an administrative function • Employment law, pensions, Health and Safety and so on
HR should be a strategic function:
• What people assets do we need for the future? • Where will we get them? • What people skills and knowledge do we need to develop and
how?
Major business change should seek to engage HR as a key stakeholder:
• May provide key insights into the effects of proposed change • Primary contact with some external stakeholders (Unions)
Communications planning involving HR is a key issue:
123
• Business change often involves sensitive/confidential activities • Requires careful planning as to how they are communicated,
when and to whom • Legislative issues in some companies • Unfavourable news to communicate
124
Aspects of Process Change Business Process: a set of tasks performed by a business in response to a business event. The business process receives, manipulates and transfers information or physical items in order to produce an output of value to a customer. FCBC Glossary.
Business events trigger business processes which proceed according to defined business rules.
• A business process should include all the steps required to create value for the customer who seeks to use the process.
• The customer may be internal or external. • The business processes are often represented on swim lane
diagrams.
Functional vs Process View
A significant problem for businesses is process identity and above all, process ownership. If sufficient care is not taken, the investment in improvements is localised to functional areas, and what seems to be an improvement in a part of the process may cause deterioration in performance elsewhere. This effect, whereby a process is locally optimised, but impacted overall is known as sub-optimisation.
Processes are independent of organisation structure – structure defines how the people in the business are organised to carry out the processes.
125
The business needs both views – i.e. a holistic view of process (e.g. using the process map) and a view of organisation structure.
Business Rules define how business activities are to be performed. It is important that these rules are considered when modelling the business processing to carry out the activity. There are two main types of business rule: constraints that restrict how an activity is performed; operational guidance that describe the procedures for performing activities. FCBC Glossary.
The Value Chain and Value System
Michael Porter’s value chain identified that we need to examine the value adding elements of any company and these should or could be the focus of improvements.
The value chain is an important model of business and critical to the work of business analysis.
Primary Activities are those activities directly related to the production of the firm’s goods or services; value creation.
126
Support Activities help to improve the effectiveness or efficiency of Primary Activities; enablers of value creation.
The Value Chain shows where costs are incurred by the organisation and where value is created for the customer (internal, or external).
Value Proposition
An organisation must be aware of what their value proposition is – this is the key to why people interact with this company, the reason they like it.
A Value Proposition is the value that a product or service delivers, or is perceived to deliver, to an organisation’s customer. FCBC Glossary.
Identifying an organisation’s value proposition means identifying the drivers that lead to increased customer satisfaction, acquisition and retention.
Generally the proposition covers three main areas:
• Product/service attributes that define the product itself • Functionality • Price • Quality • Choice • Availability
• Customer relationship aspects • How the customer feels about their experience with you
• Image and reputation • May relate to the product • May be built up through extensive advertising and
promotion to suggest the desirability
It is essential to understand the value proposition because it defines what the organisation needs to deliver to its customers and the business processes are the delivery mechanisms.
127
Hierarchy of Business Processes Granularity is a major problem in process modelling – after all at a very coarse level of granularity, the whole organisation is just one big process!
One approach is to model at different conceptual levels:
• Level 0: Organisation level – a context model shows whatever is being modelled as a black box in relation to its environment; for example ‘the business’ or a major business function such as ‘Operations’.
• Level 1: A process map shows the processes in relation to each other and their environment; however, we don’t see the detail of how each process works internally.
• Level 2: Process level – a process model shows the internal logic of the flow of each process, through a series of steps or tasks. When people talk of process modelling this is the level most people are thinking of.
• Level 3: Task level – takes each step in the relevant process model and expands the detail of it, for example as a procedure
128
document. There might be a case for including lower level diagrams here too.
Business Process Model
Business Process Model: A diagram showing the tasks needed to be carried out in response to a business event, in order to achieve a specific goal FCBC Glossary.
There are many notations that can be used to document a business process:
• Activity diagram from the Unified Modelling Language (UML) • Business Process Modelling Notation (BPMN) • The most popular is the swimlane diagram
Swimlane Diagram: a technique used to model business processes. A swimlane diagram models the business system response to a business event. The model shows the triggering event, the business actors, the tasks they carry out, the flow between the tasks, and the business outcome. FCBC Glossary.
A business process model shows:
• Actors – each ‘role’ involved in the process has a separate swimlane, it is usual for the initiator of an event to be at the top of the diagram, so this is usually the customer. There is no specific symbol used instead the name of the function or the person is used
• Tasks – the tasks are shown in the sequence that they happen. The definition of a task is one person, at one time without interruption, i.e. doing something without having to stop and check with someone else, until the task is completed and can be handed over to the next area of responsibility for further action. The symbol used is a rectangle
• Decisions – where there is an alternative route we show the decision with possible outcomes. The symbol used is a small diamond with the responses on the ensuing output flows
• Process flows – the sequence in which the tasks are performed. The symbol used is a line with the arrow head indicating direction
• Outcome – a final end point, something of value to the customer. The symbol used will depend on the drawing notation
129
• but a target is often shown
The key question is does every task contribute to the overall value?
See FCBC glossary for Business Event, Actor, Swimlane and Task.
130
Example UML activity diagram – DVD sales
131
Business Process Improvement As-is and To-be Models
When considering how to proceed with a change, it is usual to consider where you are (as-is) and where you want to be (to-be).
Business Process Improvement is an evolutionary approach, during which it’s usual to model what is in place already and then identify opportunities for improvement.
Using this approach means that the improvements identified will be based on a bottom-up approach. This is a suitable approach for small incremental changes.
Process Improvement, based on As-is
The process improvements to be considered based on the current situation are:
• Hand-offs where work is passed from one person or responsibility to someone else, these are a potential source of inefficiency and delays
• Piecemeal changes to a process over a period of time, which may have resulted in duplication, or inconsistencies or even work being done that is no longer required
• Sequential tasks rather than parallel processing may cause waiting time.
• Looping from the end back to the beginning • Ill defined, person dependent activities which could be
automated. • Redundant or conflicting tasks • Re-keying of data
By examining the current process these problem areas can be identified and targeted for improvement.
Process Improvement, based on Should-be
Sub-optimisation needs to be considered at this stage as well. By improving part of the process is there a negative impact on another part of the process?
132
Sometimes a more radical approach to change is needed and a top-down approach is called for, Business Process Re-engineering.
The starting point during this approach is to model how you want the end result to be and then create the processes to support that view.
This revolutionary form of process improvement ensures you are not constrained by current processes. It is generally more costly and riskier but can lead to a step change in effectiveness. Also this approach is essential where no current process exists.
To-be models may not be identical to Should-be however and there may be cost, time, risk, social and cultural feasibility considerations as well as disruption to Business as Usual.
_________________________________________________________
Model Versions
Process Models may be required for many different purposes:
• As-Is: models the way the process currently works. This pre-supposes that the process exists and has already been identified
• Should-Be: this is the way we would ideally like the process to work, based on strategy, Value Chain analysis etc.
• Could-Be: especially in process re-design. Often from ‘Blue-sky’ thinking to foster some creative thoughts on the process configuration
• To-Be: this is the way we design the process to work in the near future
What versions are required in a particular project will depend on the extent of the business change being made.
This syllabus does not consider the ‘should-be’ or ‘could-be’ versions.
_________________________________________________________
Linking Process and Information
Whatever the starting point is for the future change, consideration must always be given to the data and information that will be needed. The
133
tasks identified in the business process will identify data requirements but do they cover the full life cycle of that data item?
Data may have to be ‘found’ or created, or data may no longer be required and there might be consideration for data redundancy issues.
A popular and useful technique is the CRUD matrix which links data which is important to the organisation with the processes which Create, Read, Update or Delete those data items and ensures that there are no gaps in the life cycle of the data.
Mnemonic: CRUD – Create, Read, Update, Delete.
Example CRUD matrix
Add order Amend order
Complete order
Order enquiry
Order C R/U R/U R
Customer C/R/U R/U R/U R
From the CRUD matrix we can see that processes are in place to Create, Read and Update both the Order data item and the Customer data item.
But when is the data removed? No Delete process is captured on the matrix; this may be correct if this is just a partial model but even if the delete activity is outside the scope of this change it should still be noted on the CRUD matrix. Quite often, the delete activity is overlooked by the business.
134
Information Analysis and Modelling It is important to understand the information, how the data is used and the priority for the organisation.
The Information Management Model categorises information according to two dimensions:
The first dimension to consider is: what type of information it is:
• Structured – Fixed format fields containing precise information
that is defined within a data model • Unstructured - Free format information i.e. free text or
multimedia content
Secondly consider the storage or use of the Information:
• Controlled – Captured, stored in a secure and legally compliant
manner • Exploited - Analysed, reported on and used for organisational
advantage
135
Information Management Model
The contents of the quadrants are:
Data Processing - The processing and control of structured data.
Document Management - The capture and control of unstructured data.
Business Intelligence - The consolidation and analysis of structured data.
Business Intelligence is summary information that is used to manage the business of an organisation. It is derived from internal operational data and information about the external environment. FCBC Glossary.
Knowledge Management - The process of sharing and analysing unstructured data.
Information Quality - This central element ensures that the data and information contained in all four quadrants is fit for purpose.
136
Information Management strives to ensure data quality in all areas.
Information Management is the storage, control and exploitation of information in order to enable its effective use within an organisation. FCBC Glossary.
Information and Business Change
The term ‘data’ is usually used to denote isolated facts and figures without a context, it is not until the data is organised that it can communicate meaning and is then known as information.
Information is data that has been organised and arranged in such a way that it conveys meaning within a given context. FCBC Glossary.
Importance of Information
Knowledge is the accumulation of information, which is what business organisations need for decision-making at every level:
• Strategic • Tactical • Operational
Mnemonic STOp
Typically this information will be structured around critical success factors and key performance indicators.
Master Data defines the main subject areas or concepts about which the business is interested in and needs to keep data and information.
Data Governance tries to ensure an organisations data assets are formally managed throughout the enterprise to ensure it can be trusted, is re-used and there is clear ownership in place.
137
Information Analysis – Anthony’s Triangle
Anthony’s triangle depicts the hierarchical view of the management structure and the information needs at different levels.
• Day to day Operational decisions at the bottom based on large volumes of detailed information specific to a business area
• Short to medium term Tactical decisions made in the middle of the model with wider scope and less detailed information
• Few, but important, Strategic decisions at the top based on highly summarised information from across the whole organisation
• The higher in the triangle the information required is the more scope it covers and less precise it becomes.
• Conversely, the lower in the triangle the information needed is, the more detailed and precise it becomes
• The horizontal views are then sectioned vertically to take a functional view of the data across the three levels
• One major issue that has to be addressed is the physical location and storage of all this data
138
Ideally data will be centrally stored and accessible to all business functions to export and use as Information for decision making.
A data warehouse is a central repository of data which is created by integrating data from one or more disparate sources. Data warehouses store current as well as historical data and are used for creating trend reports for senior management reporting such as annual and quarterly comparisons.
See Data Warehouse in FCBC Glossary.
Case Study Exercise 4 – Data and Information Needs
139
Information Modelling and Business Rules Data modelling is the activity which is used to describe data logically during systems design. From these data models another task of database configuration is used to design the physical organisation of the data. Both these tasks are skilled data tasks and within this course we only need an appreciation of what would be involved, and the capability to read appropriate data models.
All data models show things which are of importance for the organisation to hold data about, things they want to analyse, record, investigate and report, their Master Data.
See Master Data in FCBC Glossary.
They provide a static view of data without considering the physical location of the data.
Entity Relationship Diagrams
Entity Relationship Diagrams are often used for database design.
An Entity Relationship Diagram is a diagram produced using the entity relationship modelling technique. The diagram provides a representation of the data to be held in the IT system under investigation. FCBC Glossary.
See also Entity Relationship Modelling in FCBC Glossary.
An Entity Relationship Diagram captures:
• Entities – Something (noun) the business wants to collect and store data about.
• Relationships – Relevant business relationship between data items
• Degrees of the relationship – Business rules depicting how many entities involved in the relationship
• Attributes – The underlying data that describes each Entity (not shown on an ERD but captured separately in a data dictionary)
• Entity Occurrence – Individual unique instances of an entity
140
The above model shows that each customer holds one or many accounts, but that an account is held by one and only one customer.
Relationship Optionality Within Entity Relationship Modelling the optionality of a relationship can also be expressed i.e. whether the relationship between the two entities is mandatory or conditional:
141
Class Modelling
From the object approach to systems development, using UML, Master Data can be represented using a Domain Class Diagram.
In a Class Diagram it is usual to find:
• Domain Classes - these identify subject areas meaningful to the business about which they wish to hold data and information
• Attributes - the identity and definition of individual ‘data items’ that belong to the Class
• Associations - business relationship that link Classes together • Objects – an instance of a Class • Operations – the functions the Object might be called to
perform • Multiplicity – The business rules depicting minimum and
maximum instances per Class o 0..1 (no instances or one instance) o 1..1 (exactly one instance, can be shown as just 1) o 0..* (zero or more instances, can be shown as just *) o 1..* (one or more instances) o 3..12 (minimum of 3 up to a maximum of 12 instances) o Multiplicity is used to implement business rules as you
can have a minimum and a maximum number relevant to the requirement
See Class, Class Model, Object and Unified Modelling Language in the FCBC glossary.
142
Activity 3 – Data Modelling
Aspects of Information Technology The first area to consider is Applications Development.
Software may be developed in-house or by acquiring a package.
• Bespoke development - building exactly what you want is tailor made to meet the organisation’s requirements. If your organisation has an internal IT development team then this is an approach which might be appropriate.
• Commercial off the Shelf (COTS) offers many excellent prebuilt solutions which may be suitable if the solution is standard.
• Systems Development Life Cycles (SDLC) govern the way IT systems will be developed by the organisation. They are also known as Software Development Life Cycles.
Typical phases of SDLC’s include:
• Requirements analysis • Design or Acquire • Build or Configure • Test • Implement
143
The Waterfall Lifecycle
The Waterfall (or ‘Structured’) model is the traditional approach to systems development. It provides rigour and control of the development where the requirements are known in advance. Following the feasibility study the principle is to follow prescribed IT activities:
• Analysis of the requirements • Design of the solution • Build the solution • Test the solution • Implement the solution into the company • Maintain it during its working life • Retire it when it is no longer needed
It is a robust and reliable approach. However, there are drawbacks:
• Testing is only performed once the software is built • It is quite rigid and where additional or different requirements
become known these are difficult to fit in • The implementation of anything does not happen until the whole
system is ready
144
A refinement to the Waterfall approach is the V Model, which looks to address the limitations of the waterfall approach by linking testing with development activities and also with a practical approach to validating the requirements.
The IT system is still only implemented once the full solution is complete. The phases covered by waterfall are still appropriate within the V model.
Waterfall approaches:
145
Incremental Approach (also known ad Evolutionary)
Another approach to systems development is the Incremental model:
• Development is divided up into a number of discrete phases • Each phase is planned and has targeted deliverables • The product is decomposed into components • Components are designed, built and tested separately • The product evolves through a series of releases • The implementation of an increment influences the later
increments • Integration testing of components can be complex
The incremental model is a method of software development where the model is designed, implemented and tested incrementally (a little more is added each time) until the product is finished. It involves both development and maintenance. The product is defined as finished when it satisfies all of its requirements. This model combines the elements of the waterfall model with the iterative philosophy of prototyping.
The product is decomposed into a number of components, each of which are designed and built separately (termed as builds). Each component is delivered to the client when it is complete. This allows partial utilisation of the product and avoids a long development time. It provides the user with earlier use of some of the system functionality and avoids a large initial capital outlay with the subsequent long wait for the IT system. This model of development also helps ease the traumatic effect of introducing a completely new system all at once. There are, overall, few problems with this model.
Learning comes from both the development and use of the system, where possible. The system evolves as each increment is implemented. To use this approach all requirements must be known at the start. This distinguishes the approach from an iterative lifecycle, which is described next.
Incremental Approach: an approach that delivers a developed or procured software solution in phases. FCBC Glossary.
146
Incremental Lifecycle
Evolutionary/ Spiral Model
• Evolutionary systems development may be used when a complete set of requirements cannot be gathered at the start of the project.
• This approach allows requirements to be gathered iteratively. Prototypes are demonstrated to the business user, feedback is captured and further requirements built into the next prototype.
• The system is delivered once, after a number of iterations. • The spiral model has four quadrants:
• Determine objectives • Identify and resolve risks • Development and Test • Plan the next iteration
The Spiral model is a software development process combining elements of both design and prototyping in stages. It is a risk-reduction oriented model that breaks a development project up into iterations, or ‘mini projects’, each addressing one or more major risks.
147
The spiral model was defined by Barry Boehm in 1985. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters.
As originally envisioned, the iterations were typically 6 months to 2 years long, and was intended to be used with high risk mission critical development e.g. a nuclear power station. The spiral model is used most often in large projects and needs constant review to stay on target.
Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. The software product is delivered ONCE on completion of the final iteration.
148
The iterative approach greatly influenced the development of the Rapid Application Development approach in the 1980s.
Spiral and Incremental models
149
Rapid Application Development (RAD) is a more flexible approach which aims to deliver software to the business within iterations. Instead of waiting for all the system to be complete, RAD aims to implement when the quality is acceptable to the users and there is adequate functionality for them. The approach to doing this is by:
• Timeboxing the whole development lifecycle, but in miniature, limiting the time that will be spent in development. A timebox can be as short as one week or up to 6 weeks, there are different approaches depending on the type of RAD approach used
• Prototyping as you go along, within each timebox, showing the growing system to the users for them to say Yes or No to how it is being built
• Using an integrated team of IT developers and user people, who can make decisions, is a key feature of this method of working
• Gathering requirements is the first part of any iteration, so the requirements grow with the build and are never rigid, allowing for change within the agreed timebox.
• Requires careful project management
Frameworks that use a RAD approach have been developed e.g. DSDM, Agile and Scrum.
150
Selection Criteria
An organisations can choose a different approach and acquire the solution by purchasing a software package.
Software Package: An IT application that is purchased rather than subject to bespoke development. Often known as Commercial-off-the-shelf (COTS) packages. FCBC Glossary.
Commercial off the Shelf Software (COTS)
Commercial off the shelf (COTS) software is routinely used for standard non-core functions.
One other approach to a business solution is to opt for an Enterprise Resource Planning (ERP) package. These are now mainstream solutions and can provide a full end-to-end solution across the business.
Key features of an ERP are:
• Could replace all basic office functions such as Finance, Sales, Production, HR, and many others
• Provides consistent view of data across the whole organisation • Supports end-to-end operational processes • Incorporates industry best practice • Major change for an organisation as a review of internal
processes will be required with probable modification
151
Enterprise Resource Planning is an integrated set of applications that support the operational business processes of an organisation. FCBC Glossary.
Planning the New Service
Whichever SDLC or approach to software development you adopt, the system will be with you for a considerable period of time. Built once but used thousands of times.
This is where the planning for the new service becomes of paramount importance and the involvement of the service management team is needed.
The IT Infrastructure Library (ITIL) advises standards and best practice for running and supporting the live environment which ensures:
• The service and its Configuration Items (CIs) are registered • Applications architecture are physically packaged and deployed • The service is organised, perhaps Help Desk support too • Respect for the application’s non-functional requirements (NFR)
must be assured • Backup and disaster recovery conditions must be determined • Day to day operation will not impact on current systems
Irrespective of the extent of the change, the continuance of the business must be assured. This is usually covered by disaster recovery planning and implementation.
Business Continuity is the process and procedures an organisation puts in place to ensure that essential functions can continue during and after a disaster. Business continuity planning seeks to prevent interruption of mission-critical services, and to re-establish full operation as swiftly and smoothly as possible. FCBC Glossary.
152
Post Test 4
To reinforce the materials we have just covered, try out the following questions which are in the style of the exam questions.
Answers can be found on page 194.
1. All individual process steps in a business process model, should:
A. Describe detailed business rules B. Add value to the overall process C. Cross reference processes to data D. Relate to all other processes
2. Which of the following best describes the purpose of a Business Process Model?
A. To show the tasks undertaken within a functional area B. To demonstrate the business process for an item of
software C. To show the sequence of tasks across a process D. To show the detailed business rules within a process
3. Which of the following are examples of unstructured information?
a. Email content b. Relational database record c. Graphic of a company’s logo d. Legal document A. a, c and d B. b, c and d C. a, b and c D. a, b and d
4. Which software type is most suitable for creating end-to-end operational processes?
A. Mobile Data Capture Systems B. Enterprise Resource Planning C. Business Intelligence D. Data Warehouse
153
5. Which of the following would you not expect to see as an output of a Business Change Design Phase?
A. Applications design B. Description of the ‘to be’ process C. Documented business strategy D. Training requirements
6. Which of the following best describes the term ‘Information’?
A. Information is data organised and presented in a meaningful manner
B. Information is another word for data C. Information is the name for any data that is held in an
Information System D. Information is any data that is properly obtained, collected
and stored
7. What is the primary capability provided by an Enterprise Resource Planning package?
A. It supports and links business functions with consistent data B. It manages relationships with customers and suppliers C. It provides tools to plan the finances of the enterprise D. It is a management information source for senior executives
8. Which phrase best describes the purpose of an Organisation Chart?
A. It is a map of the organisation’s processes B. It is a map of the organisation’s command and control
structure C. It is a map of the organisation’s goals and objectives D. It is a map of the organisation’s main business rules
9. Which phrase best describes the meaning of the term ‘role’?
A. A role is a group of specific individuals B. A role is a convenient collection of responsibilities C. A role is just a synonym for a Job Title D. A role is somebody’s Job Description
154
10. In the design stage of business change, which of the following topics may all need to be reviewed, since there may be some relevant impact there?
a. Strategic Goals b. People Skills c. Processes d. Information e. Technology
A. a, b and c B. e, c and a C. b, a and d D. b, c and d
11. Which of the following is not normally recognised as a Business Function?
A. Information Management B. Marketing C. Human Resources D. Operations
12. Which of the following phrases best describes the technique known as Work Practice Modelling?
A. Teaching personnel to use the new IT system functions B. Picking out where IT functions might be useful in support of
a new process C. Trying to ensure the required IT functions are integrated
conveniently within the proposed working environment. D. Reviewing whether the IT function changes have been
successful or not
155
13. The acronym CRUD is applied to link which features of IT application development?
a. Process b. Data c. Rules d. Interfaces
A. b and c B. a and b C. a and d D. d and b
14. Which one of the following would usually be classified as structured data?
A. An inter-office email B. A set of Customer address details C. An on-line video demonstration D. The contents of a letter to a Supplier
15. Which one of the following phrases most closely identifies the notion of Master Data?
E. Transactional information collected by normal business operations
F. Content of pictures, text and video G. Consolidation of transaction data into useful management
information H. Key facts relating to the principal subject areas of interest to
the business
16. In UML, data is modelled using a Domain Class Model. On the diagram, which of the following features could be represented?
a. Multiplicities b. Events c. Attributes d. Associations
A. a, b and c B. a, b and d C. b and c only D. a, c and d
156
17. One of the main virtues of using an Enterprise Resource Planning package (ERP) is:
A. They don’t need to be configured B. They never need upgrading C. Consistent approach to data definition across the enterprise D. The enterprise will never need any other software
157
End of chapter notes End of chapter notes
158
5. Business Change Implementation
Objective
To understand the processes that should be employed to deploy business change effectively
Topics:
In this section of the course we will understand:
• Planning the acquisition, deployment and acceptance • Acquiring the solution • Deploying the solution • Ensuring acceptance • Reviewing the change
159
Planning the Acquisition, Deployment and Acceptance As part of each option presented in the Business Case consideration must be given to the way in which the solution will be implemented, taking account of the impact on the users involved, the impact on the business and how the change will be achieved.
• Successful implementation relies on making an early start and working towards the final goal
• The programme or project team is responsible for all the outputs which will be required to make the change, but what methods will be used to create or acquire these outputs?
• We have examined the IT system considerations but as the change will also involve other outputs relating to people, organisation and processes we also need to consider who will create these outputs and how they are to be delivered
• Within the change team there should be individuals who are responsible for these deliverables. The format for the outputs was agreed in the design stage of the business change lifecycle, now it’s time to actually deliver them
Acquiring the Solution The design stage considered the two approaches to delivering the IT products, bespoke in-house development or purchasing a COTS package.
What are the advantages and disadvantages of bespoke development and purchasing COTS packages?
160
Bespoke vs COTS
The Need for Contracts When entering an agreement with a 3rd party to provide a COTS package, or undertake the solution development a formal contract will be required to:
• Set out conditions of supply • Contain timings and deliverables • Indicate roles and responsibilities • Define procedures for issue resolution, escalation, support
Contracts are a common risk management strategy which help to manage those unexpected circumstances to ensure a suitable solution can still be reached.
161
Business Acceptance Testing Robust Business Acceptance Testing needs to be completed prior to deployment. This is a combined business and IT test to ensure the overall flow of the finished products are fit for purpose.
The planning for this begins with the requirements activities in the Definition stage of the Business Change Life Cycle. Based on critical business scenarios the entire end-to-end process must be tested.
The V model emphasises the levels and types of testing to do including Business Acceptance Testing, which should also use business stories or journeys to ensure a joined up solution.
What the solution should be doing is one side of the testing; the other is how the system will respond to the workload and other non-functional requirements. Quite often this testing is performed by specialist teams who simulate what would happen.
A Service Level Agreement (SLA) is a standard document which defines the level of service which the business can expect when the change has been implemented into the operational environment. FCBC Glossary.
Case Study Exercise 5 – Business Acceptance Testing
162
Deploying the Solution Deployment covers the transition from having the new products available, and tested to them being installed
Close collaboration is required between the project team and the affected Business as Usual operational personnel:
• The Project team’s focus is to turn over the products to operations so that in future all the operational concerns will be handled by them
• Business operations’ focus is to ensure that the products work, the business is ready and that disruption is minimised
• Service Management’s focus is to manage the changes to the technical environment and provide a new/revised operational service
Data Migration could also be needed where the solution requires either new data or a new platform for old data. Data migration can be a particularly complex task.
• Do as much migration as possible ahead of time • Quite often data migration is handled as a separate project
within a programme as they can be long drawn out affairs with very specific issues
Implementation approaches Standard approaches to implementing business change are:
• Pilot: all of the functionality is delivered to a limited part of the overall business operations
• e.g. a ring-fenced team or a few representative offices from a large number
• Especially appropriate when the change is something very novel
• The purpose is to make sure the new concepts work as expected in real situations
• Phased: a phased approach implies a gradual roll-out of ‘chunks’ of functionality across the business or phased roll out across different business locations
163
• A Pilot is often followed by a phased roll-out. Enterprise Resource Planning (ERP) projects are examples of this approach
• Parallel Running: in this approach, both the new system and the old system are run in parallel for a certain amount of time, usually measured in ‘business cycles’
• The purpose is to ensure that the expected results from the new system are comparable with the old system
• Especially appropriate when mission critical processes are involved or there are Health & Safety issues
• Big Bang: Cut-over completely from the old to the new. • Very risky without some of the other approaches
involved previously • Often the preferred approach after parallel running
Handover Considerations
When trying to determine which approach is the most suitable, considerations include:
• Cost: parallel and pilot have special costs associated with them, which the business might not wish to pay
• Risk: if the change is a major upheaval the company may be very cautious about how they make the change
• Time: some projects just have to go in at one time; regulatory changes are a typical example
• Resources: parallel will require input to be entered twice and results checked which requires the people to manage and control this
The implementation objectives will have been set by the business and will consider the following:
• Their level of confidence in the product • The extent of disruption they can live with during the transition • Whether there is a fall back situation. If there is no alternative
but to move forward, in the case of legislation changes for example, then the choice of implementation approach may be straightforward.
164
The Change Process
Deploying the solution must also consider how the change will be received, making the changes ‘stick’ can be difficult:
• People and organisations tend to form patterns of working • People like what they know and are familiar with
Existing patterns of working often need to be changed.
Kurt Lewin’s model of change suggests three stages to focus on:
• Unfreeze: prepare people for the change, emphasising the change in current patterns that is due to occur
• Transition: make the change • Freezing or Refreeze: create new patterns, making sure
people can’t go back to the ‘old ways’. Keep up the pressure here until the change is accepted
The bigger the change in existing patterns, the harder the change will be for people to adapt to and therefore there will be increased risk that it will not be accepted.
165
Ensuring Acceptance A Force Field Analysis (Lewin) can be a useful tool to identify forces which will promote the change and those that will resist it.
It is helpful to identify where to place the effort in overcoming resistance and ensuring acceptance by improved communications, choosing change champions or other methods.
Force Field Analysis Diagram
• Change will always cause an initial dip in productivity as people learn the new processes / systems / team structures etc. that are now in place
• Also individuals’ self-esteem will be reduced as they adapt to the new working practices
• The Project team must offer support, training and encouragement to the business users as they progress through this stage to assist them in returning to full productivity in the shortest time
166
Learning Cycle
The learning cycle shows the stages:
• Unconscious incompetence – we don’t know yet how the change will impact us, what do we need to learn?
• Conscious incompetence – we know now how the change will affect us, there is so much to learn!
• Conscious competence – we have been trained in the new way of working, will I remember to do it this way?
• Unconscious competence – we can work in the new way without having to think about it
167
Emotions and the Change Process
Traditionally people faced with change also can experience the SARAH affect, the acronym stands for Shock, Anger, Rejection, Acceptance and Hope.
• When we hear the news that a change to the business is planned there will be shock, as it may be something completely unexpected and unwanted
• Anger over something where you have little or no control • Rejection or denial that it will affect you or an ‘I don’t care’
attitude • Acceptance, the deed has been done and we are here, this is
the result, new environment, new job, change has happened and we must adjust to the result
• Hope, there is a future, everything is settling down and it seems to be fine, we can do this! Time to get up to speed and become productive
168
Some Key Points
National, organisation and people cultures all affect the way that change will be accepted and should be considered by the Project team when planning for this stage.
See Business Change Management and Change Management in FCBC Glossary.
People are affected by change and need support during change.
The negative aspects of change can’t be avoided, but can be minimised by:
• Strong communications • Quality products • Training • Visible proactive support during transition • A ‘No-blame’ culture
169
Reviewing the Change
Reviewing the Implementation
The project is closed once transition has happened. There may be a period of optimisation or stabilisation after installation, supported by the project team.
Once the change has been implemented and Business as Usual has resumed the project should be the subject of a Post Implementation Review (PIR).
Post Implementation Review: focuses on the delivered product (often an IT system). It takes place relatively soon after the product has been delivered. It concerns itself with such issues as: does the software reliably and correctly meet its agreed functional and non-functional requirements; how was the project conducted and are there lessons to be learnt? Actions are agreed to tackle issues raised at the review and feedback lessons learnt into organisational standards. FCBC Glossary.
• A Programme may host several PIRs. • Previous, similar reviews should be considered as part of each
PIR. • Plans must be made by the business to conduct a Benefits
Review after months, or years after the change has been implemented.
Benefits Review
A Benefits Review focuses on:
• Whether the benefits, as defined in the business case, have been achieved
• Whether any actions can be taken to ensure as yet unrealised benefits.
As benefits take time to accrue there may be a series of reviews until a final Realisation report is produced.
Benefits Management and Realisation is covered in detail in the next section.
170
Post Test 5
To reinforce the materials we have just covered, try out the following questions which are in the style of the exam questions.
Answers can be found on page 194.
1. The term PIR stands for:
A. Post Implementation Review B. Post Initiation Review C. Project Initiation Report D. Programme Implementation Report
2. Which of the following is not a main source of documented information needed to undertake a formal review once Implementation has taken place?
A. The Business Case B. Previous similar reviews C. Stakeholder Analysis D. A summary of Costs and Benefits
3. Force Field analysis provides a way of identifying:
A. A mechanism for driving change across organisational boundaries
B. Where the change is most likely to provide the greatest value within an organisation
C. Where effort will be required in assisting change and overcoming resistance to it
D. A set of steps that will help to force through change in situations that show resistance
4. Which of the following statements does not define the need for a contract?
A. To specify a clear timing on project phases and deliverables B. To convince the customer of the reasons to set the project
up C. To identify the roles involved in the process and their duties D. To establish a clear set of conditions in a customer/supplier
relationship
171
5. Which of the following activities do not form part of the ‘unfreezing’ phase of a change?
A. Ensuring restraining forces do not regain their former influences
B. Involvement of staff in planning and preparation for change C. Identifying and addressing resistance to change D. Development of publicity campaigns to enforce key
messages
6. What should the business sponsor not be directly managing during the implementation phase?
A. Technology solution works according to the specification B. Negative impacts on the receivers of the change C. Risks that the benefits will not be achieved D. Confidence of top management in the planned change
7. Which one of the following tasks would not normally be included in the Implementation Stage of business change?
A. Designing IT Products B. Building IT Products C. Testing IT Products D. Installing IT Products
8. In which one of the following Implementation tasks is it unlikely that
the Business Analyst would have direct involvement? A. Data Migration B. User Acceptance Testing C. Hardware Configuration D. COTS parameter configuration
9. Which of the following is not part of the SARAH acronym that describes people’s typical reaction when confronted with change?
A. Shock B. Anger C. Refreezing D. Acceptance
172
End of chapter notes page End of chapter notes
173
6. Benefits Management and Realisation
Objective
To manage the classification, review and realisation of benefits.
Topics
In this section of the course we will understand:
• Classifying benefits • Investment appraisal techniques • Benefits and the Balanced Business Scorecard, CSFs and KPIs • Benefits Management in the Business Change Lifecycle • Roles and responsibilities in benefits management • The purpose, conduct and outcomes of a benefits review • Benefits realisation significance and challenges
174
Classifying Benefits Benefits are related to Outcomes
• A system change produces an expected Output • For example, Sales Orders are captured more quickly.
• This leads to an Outcome which is an effect on some Business Objectives
• For example, the volume of Sales Orders taken is increased.
Benefits may be financial or non-financial:
• Financial benefits are measurable in monetary terms and are also tangible
• Non-financial are difficult to measure in monetary terms and are called intangible
Hierarchy of Benefit Categories
They may also vary in their capacity for quantification and predictability. Ward and Daniels suggested the following Benefits Hierarchy:
• Observable - only subjective assessment by specified groups is possible
• Measurable - performance aspect is currently or potentially objectively measurable, but it is difficult to predict the size/extent of the change on the target system
• Quantifiable - sufficient evidence exists to forecast and quantify the level of benefit obtainable by the change, although measurement may not be financial
• Financial - the benefit can be reasonably accurately expressed as a financial value
As well as increasing in their ability to be measured it was suggested that this hierarchy also represented an increasing value to the business, with financial benefits being of greater value than pure Observable benefits.
However, it is not recommended that only quantifiable or financial benefits should be admitted in a business case. Even observable
175
benefits may be valuable if they are thought to improve business performance.
Costs may also be avoided by making a business change, in which case the avoided cost is shown as a benefit of the project.
See Benefits Realisation in FCBC Glossary,
176
Investment Appraisal Techniques Every project requires funding by the organisation and potentially there will be a number of projects requiring investment. It is usual to use cost-benefit analysis to compare the level of investment and the predicted return on that investment to enable organisations to make informed decisions. However, there may be mandatory projects which must be completed for legislative reasons, these do not always need a cost-benefit analysis.
• An investment appraisal is a series of measures to assess the validity in financial terms of proceeding with an investment.
• Based on estimates of net benefit vs. investment costs, the project must accumulate the appropriate figures for decision making.
Investment Appraisal techniques:
• Payback period • Discounted Cashflow (DCF) / Net Present Value (NPV) • Internal Rate of Return (IRR)
Payback Calculation
177
• The table shows a typical structure for a Cost-Benefit Analysis (CBA), which only applies to tangible data.
• The normal time frame is 3 to 5 years (or the life of the asset) – the time span should be tied to the strategic planning horizon.
• Payback is the cashflow forecast for the investment using current values and advises the time it will take to get the initial investment back (the investments Break Even Point – BEP)
The Payback period is calculated by:
• Calculating the initial costs (Yr. 1). The cost to devise and implement the change
• Calculating the on-going costs. These are costs associated with the new changed situation
• Calculate the benefits. The financial benefits accruing after the change is made
By accumulating the net benefit we can see that this project will break-even sometime during Year 4.
Payback calculation does not take into account the time value of money. Due to interest rates and inflation the value of money is likely to decrease over time.
178
Discounted Cash Flow and Net Present Value
Discounted Cash Flow/Net Present Value (NPV) – cash flow forecast for the investment using discounted cash flows to take account of the time value of money.
• Management accountants provide a discount factor to apply to the cash flow forecast. This discount factor takes account of the likely interest rate changes
• The Discounted Casflows (DCF) are accumulated to give a Net Present Value (NPV) for the project.
• We can see the overall worth of this project (its Net Present Value) is £25, 210
Internal Rate of Return (IRR) – The rate of return a project is expected to generate, expressed as a single percentage figure
• To calculate IRR work back from a NPV = 0 at a fixed point in the future e.g. 5 years, to calculate the % discount rate that would have had to be applied to achieve NPV = 0
Project teams should engage with the Finance team early in the project lifecycle to understand what is of principal importance to the organisation and obtain support in perform the various calculations
See Cost-Benefit Analysis, Discounted Cash Flow, Internal Rate of Return, Payback Calculation and Net Present Value in FCBC Glossary.
179
Balanced Business Scorecard, CSFs and KPIs
A Balanced Business Scorecard supports a strategic management system by capturing both financial and non-financial measures of performance. There are usually four quadrants – Financial, Customer, Process, and Learning & Growth. FCBC Glossary.
Mnemonic CLIF – Customer, Learning and growth, Internal business process, Financial
Financial Perspective - measures reflecting financial performance, for example number of debtors, cash flow or return on investment. The financial performance of an organisation is fundamental to its success. Even non-profit organisations must make the books balance. Financial figures suffer from two major drawbacks:
• They are historical. Whilst they tell us what has happened to the organisation they may not tell us what is currently happening, or be a good indicator of future performance
• It is common for the current market value of an organisation to exceed the market value of its assets. The excess value can be thought of as intangible assets. These figures are not measured by normal financial reporting
180
Customer Perspective - measures having a direct impact on customers and their satisfaction, for example time taken to process a phone call, time to deliver the products, results of customer surveys, number of complaints or competitive rankings.
Business Process Perspective - measures reflecting the performance of key business processes, for example the time spent prospecting, number of units that required rework or process cost.
Learning and Growth Perspective - measures describing the company's learning curve -- for example, number of employee suggestions or total hours spent on staff training.
Balanced Business Scorecard is a method and a tool which includes:
• A strategy map where strategic objectives are placed over four perspectives in order to clarify the strategy and the cause and effect relationships that exists among them
• Strategic objectives which are smaller parts of the strategy are interlinked by cause and effect relationships in the strategy map
• Measures directly reflecting strategy. Their prime purpose is to measure that the desired change or development defined by strategic objectives actually takes place
• Strategic initiatives that constitute the actual change as described by strategic objectives
The scorecard drives implementation of strategy using the four perspectives shown above.
Companies are using the scorecard to:
• Clarify and update budgets • Identify and align strategic initiatives • Conduct periodic performance reviews to learn about and
improve strategy
Specific measures are chosen based upon the organisation's goals. Typically organisations "get what they measure" so care in creating measures and revisiting the measures regularly is recommended by most practitioners.
181
Linked to Business Objectives
A fairly common approach to establishing Critical Success Factors (CSFs) and Key Performance Indicators (KPIs) is to breakdown strategic goals into factors that influence their achievement. This may occur at various levels, building up a hierarchy.
Critical Success Factors: the areas in which an organisation must succeed in order to achieve positive organisational performance. FCBC Glossary.
Key Performance Indicators: these are defined performance areas that may be measured in order to assess the performance of an organisation in the areas defined by the critical success factors. FCBC glossary.
The breakdown continues until factors are identified that can be measured. At which point, 1 or more KPIs are created to establish what needs to be measured.
Finally, targets are assigned within the current budget cycle.
• CSF + KPI + Target = tactical business objective, in support of strategic goals
• CSFs and KPIs should be balanced across the four perspectives of the BBS.
182
Benefits Management in the Business Change Lifecycle One of the most essential parts to any business change programme is to ensure that the benefits are identified, classified and managed so that they are realised.
Time is often needed before a final picture is known; sometimes years to achieve a change so management of the benefits is required.
Benefits Management is the identification of potential benefits, their planning and tracking, the assignment of responsibilities and authorities and their actual realisation as a result of investing in business change. FCBC Glossary.
During a change project benefits are defined as part of the business case and reviewed when relevant to ensure that they are still valid, or to assess the impact of changes upon the benefits.
Following deployment of the change, a series of benefits reviews should take place, comparing actual benefits with those that have been predicted.
A benefits realisation report will be produced as a result of these reviews. Further actions may be identified which will support the realisation of the benefits.
183
Roles and Responsibilities in Benefits Management The sponsor, business change manager, business process owners, project team and finance team all have a role to play in benefits management.
Roles involved in the Business Case
Sponsor
•Owner of outcomes•Responsible for
authorisation of funds
Project Manager
•Produces the business case and updates it regularly
Finance team
•Produce financial information
•Keep a watching brief over progress
Business Managers
•Sign up to produce evidence of benefits
184
Roles involved in making it happen
Roles involved in the Benefits Review
Sponsor
•Unless identified as a benefit owner, just keeps an eye on the overall objective.
Project Manager
•Maintains the business case in line with expenditure
Finance team
•Receive regular updates on project progress in particular the expenditure on the project
Business Managers
•Gather the evidence that will be needed.
•Monitor current activity for future comparison
Sponsor
•Manage the process•Ensure review
happens within a practical timeframe
Finance team
•Produce financial information
•Question the results
Business Managers
•Provide tangible evidence
•Justify results
185
The Purpose, Conduct and Outcomes of a Benefits Review The purpose of a benefits review is to establish whether the benefits promised in the business case have been achieved.
A date for conducting a benefits review should be set by the project manager in consultation with the business sponsor. The date must relate to a time when business as usual has been restored and the business has had sufficient time to ‘realise’ the benefit.
See Benefits Review in FCBC Glossary.
The questions which are fundamental to the review are:
• Did we achieve the benefits we predicted? • If not what more needs to be done?
The benefits review must include all the stakeholders who are responsible for delivering the benefits and users of the changes.
Since the implementation stage the benefits should have been monitored to ensure that the information is available for this review.
The style of the review must be appropriate. This is not a blame finding exercise but a real opportunity to ascertain if the project has delivered what the business wanted or needed.
Conduct must be:
• Impartial • No blame culture • Not a fault finding exercise • Evidence based • Documented
186
The Outcomes are:
The business run the review assisted by the business analyst, the results are fed back into the programme as there may be other projects still working to complete the overall change. There may be several reviews as benefits take time to appear and projects will deliver at different times.
As with all project activities this review should be seen as an opportunity to improve the benefits management process or the change processes. It is also a chance to review any lessons that could be gained from the process of making the change.
Evidence in the form of a formal report
Lessons learnt for
future projects
Process improvement
Arrange to quantify any
other benefits
187
Benefits Realisation: Significance and Challenges Benefits Realisation: a process that is concerned with the delivery of predicted business benefits defined in the business case. This process includes managing projects such that they are able to deliver the predicted benefits and, after the project has been implemented, actions required to enable their delivery. FCBC Glossary.
The business needs to demonstrate that the investment made in terms of the money, time and effort was worthwhile.
Benefit reviews are an opportunity to review the process of project authorisation and suggest improvements.
Challenges that companies face can include:
• Political factors – as the sponsor doesn’t want to admit that benefits have not been realised
• Focus is lost when the project team disbands – the business do not take on their responsibility for managing the benefits
• BAU takes priority – resources are not tasked with managing benefits
• Other projects changing the BAU environment – making it difficult to define which project produced which benefits
• Changes to resources within the business areas – i.e. (Business Managers / Benefits Owners) means focus is lost and benefits tracking and realisation doesn’t complete
188
Post Test 6
To reinforce the materials we have just covered, try out the following questions which are in the style of the exam questions.
Answers can be found on page 194.
1. What is always a characteristic of a key performance indicator?
A. It is calculated using a computer system B. It is capable of being quantified C. It is applicable to all business functions D. It measures the performance of a manager
2. What do the initials CSF stand for?
A. Change Solution Factors B. Change Success Factors C. Critical Success Factors D. Critical Solution Factors
3. Which of the following is not a type of tangible benefit?
A. Higher customer satisfaction B. Increased revenue C. Reduced working capital D. Lower fixed asset investment
4. Which of the following is an example of a tangible benefit?
A. Higher customer service level B. Headcount reduction C. Environmental improvement D. Greater employee satisfaction
5. What is the main purpose of tracking benefits?
A. Identify emerging opportunities to increase benefits B. Justify incentives to business sponsors C. Monitor benefits against expectations and targets D. Ensuring an accepted business case
189
6. Which one of the following groups represent a widely recognised hierarchy of benefits?
A. Measurable, Quantifiable, Financial, Objective B. Observable, Measurable, Quantifiable, Financial C. Subjective, Non-financial, Quantifiable, Financial D. Objective, Financial, Quantifiable, Subjective
7. In which document(s) would you search for the original signed off statement of expected benefits?
A. Terms of Reference B. Business Case C. Post Implementation Review D. Risk register
8. Which one of the following stakeholders in business change owns the Benefits that are supposed to be realised?
A. Business Analyst B. Project Manager C. Sponsor D. IT Director
9. Which of the following descriptions is most suitable as a definition
of the essential purpose of the Balanced Scorecard (BBS)? A. The BBS shows in which features of the business we
should be targeting our investments in IT B. The BBS shows which features of the business are most
critical to focus on for the eventual realisation of strategic goals
C. The BBS shows how Financial factors are translated into Customer factors
D. The BBS shows how to organise the enterprise Management Information System for best effect
10. The point in the business change life cycle where Benefits are finally reviewed and measured is?
A. During the project close out meeting B. At the end of the design stage C. During the Benefit Review D. During the Post Implementation Review
190
11. In a cost-benefit analysis, the payback period is a measure of:
A. The point at which total estimated benefits equals total estimated costs
B. The time required to finish the project C. The date at which the supplier must be fully paid D. The period over which the initial investment is written off
12. Which of the following would normally be considered an intangible business benefit?
A. Reduction in headcount B. Release of inventory C. Improved Management Information D. Avoidance of compliance fines
13. Consider the following table of projected costs and benefits. In which year will this analysis show a Break-even point?
£000s Year 1 Year 2 Year 3 Year 4 Year 5 Benefits 0 75 85 95 100 Costs 100 10 15 20 25
A. Year 2 B. Year 3 C. Year 4 D. Year 5
191
End of chapter notes
End of chapter notes
192
Answers to Post Tests
TEST 1 TEST 2 TEST 3
Answer Answer Answer
1 D 1 B 1 C
2 C 2 A 2 C
3 A 3 C 3 B
4 A 4 B 4 B
5 D 5 A 5 B
6 D 6 C 6 D
7 A 7 D 7 B
8 A 8 B 8 D
9 C 9 B 9 A
10 D 10 B 10 B
11 C 11 D 11 C
12 C 12 C
13 A
14 B
15 C
16 B
17 D
18 B
19 C
20 C
193
TEST 4 TEST 5 TEST 6
Answer Answer Answer
1 B 1 A 1 B
2 C 2 C 2 C
3 A 3 C 3 A
4 B 4 B 4 B
5 C 5 A 5 C
6 A 6 A 6 B
7 A 7 A 7 B
8 B 8 C 8 C
9 B 9 C 9 B
10 D 10 C
11 A 11 A
12 C 12 C
13 B 13 B
14 B
15 D
16 D
17 C
194
Index Actor, 129
Balanced Business Scorecard, 174, 180, 181
Benefits Realisation, 105, 174, 183, 188
Benefits Review, 21, 170, 174, 183, 186
BPI, 16
BPR, 16
Business Activity Model, 89, 133
Business Actor, 35, 129
Business Analysis, 6, 24, 36, 74, 126
Business Case, 105, 106, 108, 117, 160, 170, 175, 186, 188
Business Change Lifecycle, 21, 27, 160, 183
Business Continuity, 152
Business Environment, 43, 45, 46, 49
Business Event, 125, 129, 130
Business Intelligence, 136
Business Perspective, 79
Business process, 16
Business Process, 35, 68, 79, 90, 122, 125, 127, 132, 134, 152, 163, 181, 184
Business Process Improvement, 16
Business Process Model, 129
Business Process Reengineering, 16
Business Requirements Elicitation, 74, 94
Business Rule, 125
Business Sponsor, 34, 108, 186
Business System, 36, 81, 82, 90, 102, 122, 129
Business User, 76, 79, 95
Change Management, 35, 69, 103
Class, 134, 142
Class Model, 142
Competency, 19, 20, 122
Core Competence, 19, 20
Cost-Benefit Analysis, 98, 177, 179
Data Warehouse, 139
Discounted Cash Flow, 98, 179
Enterprise Architecture, 22, 36, 43, 45, 61, 65, 66, 67
Enterprise Resource Planning, 151, 164
Explicit Knowledge, 76
External Business Environment, 44, 45
Force Field Analysis, 102, 166
195
Functional Requirement, 170
Gap Analysis, 74, 90
Holistic Approach, 24, 74, 81, 82
Impact Analysis, 102
Incremental Approach, 146
Information, 107, 109, 116, 117, 125, 133, 135, 136, 137, 138, 142, 143, 186
Information Management, 135, 137
Intangible Benefit, 100
Intangible Cost, 100
Internal Business Environment, 43, 45, 49
Internal Rate of Return, 98, 179
Interview, 75, 77
IT Enabled Business Change, 11, 12
IT Governance, 43, 60, 61, 65
IT System, 37, 62, 82, 140, 143, 145, 160
Key Performance Indicators, 137, 182
Net Present Value, 98, 179
Non-Functional Requirement, 96, 152, 162
Object, 142
Option, 24, 35, 36, 50, 62, 75, 91, 101, 160
Organisation Boundary, 119
Organisation Structure, 12, 24, 35, 60, 81, 118, 121, 125
Organisational Culture, 43, 56, 119
Outsourcing, 11, 19, 20
Payback Calculation, 98
Performance Measurement, 123
PESTLE, 46, 47, 48, 53
Porter’s Five Forces, 46, 48, 53
Post Implementation Review, 170
Problem Solving, 16
Process, 6, 16, 18, 19, 23, 50, 52, 54, 62, 65, 67, 75, 79, 81, 85, 101, 105, 107, 116, 117, 125, 129, 133, 136, 147, 159, 162, 164, 181, 187
Process Model, 90, 129
Programme, 116, 117, 160, 163, 170, 183, 187
Programme Manager, 27, 36
Project, 108, 109, 117, 147, 148, 160, 163, 164, 170, 177, 179, 183, 187
Project Initiation Document, 117
Project Manager, 107, 108, 186
Requirement, 36, 69, 75, 94, 95, 97, 104, 105, 108, 121, 134, 143, 144, 145, 150, 162
Requirements Catalogue, 97
Requirements Management, 94, 97
Rich Picture, 28, 78, 85
Risk, 20, 24, 27, 60, 62, 63, 75, 98, 101, 109, 147, 148, 164
196
Risk Management, 43, 60, 62, 63, 161
Root Definition, 89
SMART, 51
Soft Systems Methodology, 84, 85
Stakeholder, 11, 27, 29, 36, 75, 94, 98, 104, 108
Stakeholder Analysis, 23, 29
Stakeholder Management, 29, 108
Strategic Analysis, 45, 52
Strategy, 13, 23, 43, 44, 48, 50, 53, 61, 63, 65, 68, 161
Swimlane, 129, 130
Swimlane Diagram, 129
SWOT, 48, 50, 52, 53
SWOT Analysis, 53, 54
Systemic Thinking, 81
Tacit Knowledge, 35, 76
Tangible Benefit, 100
Task, 51, 56, 69, 109, 120, 121, 125, 129, 132, 140
Task Modelling, 122
Unified Modelling Language, 129
Use Case, 97
Use Case Description, 97
Use Case Model, 97
Value Proposition, 127
VMOST, 50, 53
Work Practice Model, 121
Workshop, 28, 75, 78
197
Contact us:0845 757 [email protected]
Must take two core courses Must take oneknowledge-based course
Must take onePractitioner course
Four courses and exams in total
Exam preparation workshop (recommended)
Diploma oral exam
BCS Certificate in Business Analysis Practice
3 days
Exam:1 hour 15 mins
BCS Certificate in Require-ments Engineering
3 days
Exam:1 hour 15 mins
BCS Certificate in Commer-cial Awareness
3 days
Exam:1 hour
BCS Foundation Certificate in Business Analysis
3 days
Exam:1 hour
BCS Foundation Certificate in Project Management
3 days
Exam:1 hour 15 mins
BCS Certificate in Modelling Business Processes
3 days
Exam:1 hour 15 mins
BCS Certificate in Systems Modelling Techniques (Structured)4 days
Exam:1 hour 15 mins
BCS Certificate in Systems Development Essentials
3 days
Exam:1 hour 15 mins
BCS Certificate in Systems Modelling Techniques (UML)4 days
Exam:1 hour 15 mins
BCS Foundation Certificate in Business Change
3 days
Exam:1 hour