Business Analyst (BA) and Analysis
To survive or preferably thrive, organisations cannot stand still. They must evolve and progress to remain alive. Such evolution and progress requires projects. And to ensure a project succeeds, among other things, it often helps to involve a business analysts (BA) particularly for complex technological endeavours. BAs aim to ensure we PMs produce the right products first up. The core thing about business analysis is engaging with project stakeholders and product users sufficiently to accurately elicit product requirements, to develop a sound business case that justifies the investment, and to create positive change for the organisation through the effective introduction and assimilation of the new product or service into business-as-usual routine. Essentially, BAs are agents for change.
BAs seek first to understand the organisation as it is and then imagine how it could be. They shape their understanding of this desired future by listening to management, stakeholders, subject matter experts and project managers. They then determine how best to get the business from where it is now to where it wants or needs to be. To BAs, the way things are now is merely a starting point for a better future.
Given this thirst for progress, there has been considerable growth in the business analysis discipline or perhaps it’s now better described as a profession growing towards maturity. And it’s a decently paid profession too. At present, junior BAs have an annual salary of $65K to $80K, senior BAs sometimes over $100K, and BA contractors charging say $150 to $200 per hour. Given this income, more and more talented people are pursuing business analysis careers.
A BA lead is often a senior BA working on projects of large enough scope that they demand the efforts of multiple BAs. In addition to performing BA activities, a lead will coordinate and oversee the work of other BAs for a specific project.
The BA’s career prospects are also good and if they prove to be competent they may progress to management consultancy, general management, and project management roles. However, business analysis can be hard work and mentally taxing, particularly when there are multiple programmes, projects, users and stakeholders to contend with. Also, stakeholders and users may disagree among themselves over requirements, simply don’t know what they want, keep changing their minds, resist change or are unenthusiastic about the prospect of change, and are unavailable or reluctant to share information. Aside from business experience, a very tolerant and persevering attitude, and an appropriate formal qualification, most importantly BAs need to be:
- Constantly challenging their organisation’s status quo.
- Able to identify and prioritise areas for business improvement.
- Curious, logical, methodical, patient, and expert listeners.
- Able to work well under pressure to meet tight deadlines.
- Good at communicating orally and in writing.
- Able to consult, negotiate and resolve conflict.
- Able to build sustainable relationships with stakeholders.
- Able to deliver effective presentations.
- Skilled at analysing, planning, problem solving and decision-making.
The roles and responsibilities of a BA are varied, but in essence business analysis is about recognising business needs, problems and opportunities, and finding viable solutions to these that create value for the organisation. The BA will elicit requirements from stakeholders, develop solutions, and manage these solutions to secure business case benefits that are of value to stakeholders. The BA’s task is to identify the business problem and get the group of involved stakeholders to collaborate on a solution to that problem. The business analyst is rarely the owner of the solution.
Can both a BA and a PM (project manager) work on the same project? The answer, of course, is yes, they can, but this depends largely on the project type, size, novelty, and complexity. Their joint and respective responsibilities do need to be agreed, and their on-going communication and collaboration is vital. To help clarify the BA and PM respective responsibilities, there are two types of project scope:
- Solution or product scope is defined prior to project initiation and describes what product is needed to sort out the business problem or opportunity to realise business benefits. This belongs in the BA domain. They manage the product.
- Project scope is defined during project planning and comprises the work needed to produce the product as per the product scope or specification, and to do so on time and within budget. This belongs to the PM domain. They manage the project.
The PM focuses on the creation of the product, service, or result (ie, deliverables) in order for the project to meet its objectives. The BA aims to understanding the needs of the business stakeholders and defines the characteristics of the solution to meet those needs. In essence, BAs are responsible for discovering the problem and determining the solution, and PMs are responsible for delivering the solution. While the PM is managing project time, resources, budget, and project scope, the BA is refining requirements, managing the product scope, and preparing the organisation for the change.
As the BA it’s important to develop a good working relationship with your PM: know your own strengths and weaknesses, and then, before the project begins, get to know the PM. Also take time to discuss the characteristics of the project (objectives and stakeholders) to make sure you both have the same understanding. Also talk about the approach (waterfall, agile, and so on) to be used and discuss how you’re going to elicit, analyse, and communicate requirements. Finally, have a chat about how the two of you can best work together.
Businesses are starting to recognise that requirements and stakeholders, need more than just management or documentation and that different skill set and focus (business focus, not project focus) is needed to effectively develop requirements. It is suggested that dual project leadership, the PM focused on the project and the BA focused on the solution, increases project success rates.
One common source of contention between BAs and PMs is the issue of project scope change. It’s not unusual for PMs to advise against changing the project scope by adding or changing features and functions to the product scope as the project proceeds, since such changes usually impact the project schedule and budget, while BAs recognise that changes to the project scope are needed to meet stakeholders’ often evolving requirements. One advantage that Agile has over a Waterfall project management methodology, is that Agile, as the name might suggest, better allows for changes throughout the project life span, although this usually means that the project needs more time and cost given the necessary trade-offs that such variations require.
The biggest difference between Agile and Waterfall is that typically in Agile the deliverable is produced and accepted incrementally, around short iterations (usually of about 1-2 weeks). Additionally, using Agile, requirements are normally more fully defined during each iteration or sprint, rather than at the start of the entire project in a single requirements phase. However, Waterfall, which is plan-driven and characterised by upfront planning, is not an all-or-nothing proposition. While the client knows from the start what to expect in terms of time, cost and benefits, the Waterfall project plan is not fixed, but is a baseline for change. Rolling wave planning or progressive elaboration originated in Waterfall. Also, providing that new requirements add value, they can be included at any time, albeit that the project schedule and budget may then need to be reset.
- Communicate with colleagues to understand the needs of the business
- Work with stakeholders to understand the service or product required
- Conduct surveys, workshops, and analyse data
- Create solutions for strategic and operational change
- Invent or alter processes to implement positive change
- Write reports to present to stakeholders
- Ensure that the project team is set up for success
- Support users as solutions are implemented
- Evaluate impact of changes made.
BA Credentials. To undertake these responsibilities, ideally BAs need:
- Industry knowledge
- Familiarity with project management methodologies
- Technical skills about database, architecture, frameworks, and systems
- Planning, problem-solving, creative, analytical and decision-making skills
- Sound mathematical skills
- Good verbal, written and active listening skills
- Good interpersonal skills such as influencing, emotional intelligence, teamwork, and leadership
- Stakeholder engagement skills
- Facilitation, negotiation and conflict management skills
- Personal time management skills
- Presentation and report-writing skills.
Principles. Principles don’t guarantee success and are ignored at our peril, but do help ensure BA effectiveness:
- Focus On The Product to make sure the real problem is solved and that there is some discernible benefit to the organisation. It’s important to think about the “why” before going ahead, thus preventing a project that provides little or no value to the organisation.
- First Define The Problem by spending some time up front to make sure we have the real problem that needs solving. Asking “why” several times often reveals the root cause, rather than merely symptoms.
- Eliciting Information is not about finding the right individuals to talk to; it’s finding the right information regardless of source. It’s about discovering the real needs behind the project. Interviews are the most popular way to elicit project requirements. They also help us understand the project from the user’s point of view.
- Separate Elicitation From Analysis by keep premature judgment and analysis out of the elicitation process. Gather first, then analyse is the mantra.
- Gain Acceptance Before Approval by ensuring the project can be done within the project constraints (ie, scope, time, cost, quality) before seeking approval for funds or resources to implement the solution.
- Make Sure The Business Community Is Ready For The Product Or Solution since the problem is not solved and business case benefits are not realised until the solution is accepted and is properly used. Change management including user training are important.
Business Analysis Process. The following process that looks particularly at the business case is more dynamic than this step-by-step approach may suggest. Some steps may need to be revisited when things go bump in the night or new information becomes available. The novelty and uncertainty of a project environment constantly throw up surprises.
- Identify Need, which requires we understanding the problem – the real problem – often identified as a result of any or all of the following three more popular tools designed to analyse our business:
- – PESTLE(C) – assesses political, economic, social, technological, legislative, economic, and competition factors.
- – SWOT Analysis – analyses our organisation’s strengths, weaknesses, opportunities and threats, given the organisation’s purpose/mission and core values.
- – Porters Five Forces – used to analyse an industry’s attractiveness and likely profitability by evaluating competitive rivalry, supplier power, buyer power, threats of substitution, and threats of new entry.
- Consider Perspectives, which requires we identify project stakeholders – those who may be impacted by the prospective project or those who may impact project success. Stakeholders can be assessed and prioritised in terms of their influence and interest. Stakeholder identification, analysis and engagement continues throughout the project.
- Define Product Scope, which concerns the features and functions to be possessed by the project product. Functions describe what something does. For example, a messaging app allows us to communicate. Features are the tools that accomplish functions. For example, a “send” button on a messaging app is a feature.
- Evaluate Options, which requires that viable options, such as build, buy or hire, for tackling the project be assessed against relevant weighted selection criteria. Suppose the NZ Ministry of Foreign Affairs and Trade (MFAT) needs to decide the best project option for reducing a Pacific Island’s reliance on fossil fuels for electricity generation. The selection criteria or attributes are first identified, prioritised and quantified, as a basis for evaluating project options:
- Prepare Justification, which requires the preparation of a Business Case to demonstrate that the proposed project is worth implementing. Projects should not be initiated or continued unless business case benefits sufficiently exceed costs, appreciating too that the Business Case is a “living document” and needs to remain desirable, viable and achievable.
- – A business case is the arguably the most important part of a programme or project, identifying if the endeavour is worth starting. It also influences whether the project continues or stops. A good business case will explain the problem, opportunity or compliance requirement, identify possible options to address it, evaluate these, and suggest which course of action is preferred. Although business cases tend to be associated with large-scale investments, business cases are just as important for smaller projects or developments.
- – BAs are interested in benefits. A benefit is a measurable improvement or positive change perceived as an advantage by one or more programme or project stakeholders. Immediate, direct, quantitative, and assured benefits are usually the most persuasive. The Five Case Model is the UK Government’s best practice approach to business case preparation, which with some adjustments has been adopted by the NZ Treasury who encourage its use for more expensive large-scale projects undertaken by our state sector organisations, local government, and District Health Boards. This model maintains that there are only ever five questions that any governing body or decision-maker wants the answer to if they are going to invest in a programme or project, and those questions are: Is there a compelling case for change? Does the preferred investment option optimise value for money? Is the proposed deal commercially viable? Is the spending proposal affordable? How can the proposal be delivered successfully? These questions are articulated in the Five Case Model that classifies costs and benefits as strategic, economic, commercial, financial, and management, which are typically assessed in that sequence. The business case should then be used during the project implementation stage as a reference point for monitoring progress and ultimately as a basis for assessing project success.
- – Some may argue that indirect benefits are too tenuous to legitimately include in our business case and if a benefit can’t be measured it shouldn’t be claimed. I suggest any benefits might be relevant, providing we also consider the associated cost and include a realistic assessment of their probability. For example, if an indirect benefit has an estimated 70% likelihood of occurring, assuming a direct or primary benefit of similar likelihood first occurs, the secondary or indirect benefit would then only have an estimated 49% likelihood of occurring (ie, 70% x 70% = 49%). However, such probability predictions are usually very difficult to make and particularly so for pioneering projects about which we have no history.
- – All this is very good, but the current Labour government doesn’t seem to believe that a business case is necessarily needed for public investments. It seems to me that Labour is pushing through some ill-thought-out policy that generates risky projects. National is about business. Labour is about emotion. In fact, Labour now seems to be the welfare class party, not the working class party. Perhaps, when the public’s love for Jacinda (and her baby) weakens, then we’ll have a change of government and business cases will be back in vogue. For example, perhaps the $36 million for the Pike River mine re-entry venture would be much better spent elsewhere. Most of the families involved in this disaster, presumably tired of being political footballs, would much prefer that whatever remains of the deceased miners be left undisturbed. However, a more likely scenario is that this extraordinary waste will continue, no bodies or criminal evidence will be discovered, and whitewash reports that somehow justify the $36 million of taxpayers’ money will eventually be published, and the venture declared a great success.
Business Case Template. A written business case might also have a title page, approvals, distribution, a contents page, and an amendment record since it’s a “living document” subject to periodic updating as circumstances change. The following is a template for a simple project:
Depending on the length of the business case we may want to include a summary that mentions the main benefits and costs, and our recommendation. Although the summary appears first, it’s written last, when we know what we are summarising.
|2. Statement of Problem or Opportunity
Describe the business need, problem or opportunity that the project will address.
|3. Analysis of Options
What are the best alternatives to solve the problem? Here we identify and describe feasible options to solve the problem or capitalise on the opportunity. Basic options may be to outsource the project work or do it ourselves. Buying the product off-the- shelf or leasing may also be options. For example, our options to feed the family are to prepare a meal at home, to get takeaways, or visit a restaurant. The final business case may contain say three or four options that usually include a “do nothing” or benchmark option. And for each option, we need to discuss:
• Benefits. We explain why it would be a good idea to do the project. Benefits may be both qualitative (intangible) and quantitative (tangible / measurable). If benefits are not measured, or are not measurable, then insufficient evidence may exist to justify the investment in the initiative. Informed and accurate decisions around business cases cannot be made unless disbenefits are also identified and measured. Different projects can’t claim the same benefits. For a particular project, benefits to be realised during the next 12 months might be:
Reduce sales administrative costs by 30%.
Increase sales by 5% to 10%.
Lose no existing clients.
Eliminate all errors in the ordering process.
• Disbenefits. We should also identify any significant disbenefits. For example, perhaps the new photocopier will run more quickly but require more maintenance. A very common disbenefit is a reduction in productivity during the time taken for users to learn to properly use a new project product. Of course, disbenefits should not outweigh benefits.
• Costs. We include estimated whole-of-life product costs that include on-going operational, maintenance and support costs.
• Timescale. Estimate of the project duration and time until we see a return on the investment – the financial breakeven point – sometimes years.
• Assumptions and Risks. An assumption is a circumstance or event outside the control of the project that can affect its success, and a risk is a potential problem or opportunity that may impact project success.
Our estimates should be realistic and wherever possible supported by solid data. Also, we need to be balanced in our assessment, meaning for example if indirect, long-term and qualitative estimates are used to determine benefits, the same criteria should also be used for costs to help ensure a fair comparison. However, usually greatest weight is given to short-term, tangible or measurable and direct benefits and costs. We should avoid relative terms such as “better”, “lighter”, “cheaper” etc. We might also mention here the consequences of doing nothing. If the return on investment can be quantified as dollars in the form of savings or profits, that will be a great help in building our business case.
|4. Recommended Option
Here we state our preferred option and explain why it’s recommended.
|5. Outline Plan
We provide a brief explanation here about how the implementation of the preferred option should proceed.
- Prepare BA Plan, which shows how we intend to go about the process of business analysis from project conception until benefits are realised. As we gather all the information about the people, project characteristics, and process, our business analysis plan takes shape. It determines how we go on to elicit, analyse, and communicate requirements, as well as what working products and deliverables we will develop as BAs.
- Elicit Requirements, which requires we engage with the stakeholders to identify their needs. Some key elicitation principles in order to find out what the business truly needs are: Listen, don’t dictate. Probe, don’t interrogate. Discuss, don’t assume. Observe, don’t accept. Evoke, don’t suppress. Requirements should be “SMART” and might be functional (these that specify what a system will do – “print invoice”) or non-functional (product constraints such as compliance, performance, reliability, and usability), gathered using a variety of techniques, including:
- – Brainstorming
- – Document Analysis
- – Focus Groups
- – Interface Analysis – deconstructs the way that a user interacts with an application, or the way one application interacts with another.
- – Interview – first using “open-ended” questions
- – Observation (Job Shadowing) – might be passive or active.
- – Prototyping
- – Requirements Workshop
- – Reverse Engineering
- – Survey / Questionnaire
One method of documenting and communicating requirements is by Use Case, which is a description of how a person who uses a process or system will accomplish a goal. It is typically associated with software systems, but can be used in reference to any process. A good Use Case will record what is going to happen from the trigger to the goal and is sometimes summarised in a graphical representation.
Some of the challenges faced by the BA when eliciting requirements are:
- – Problems of scope. The boundary of the system is ill-defined or the customers/users specify unnecessary technical details that may confuse, rather than clarify, overall objectives.
- – Problems of understanding. The customers/users are not sure of what is needed, don’t have a full understanding of the problem, have trouble communicating needs, omit information that is believed to be “irrelevant” or “obvious,” specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous or untestable.
- – Problems of volatility. The requirements change over time, which is more likely with longer-term projects. The rate of change is sometimes referred to as the level of requirement volatility. Beware too of the “sunk cost” trap.
- Support Implementation, which on immediate completion, project success, rewards and recognition are usually measured in terms of project objectives (scope, time, cost and quality) and not whether products yield their intended benefits. However, contemporary project management aims to transition project outputs into new operational business-as-usual capabilities and follow through to the achievement of outcomes, benefits and finally the organisation’s strategic objectives.
- Adopt Product, the success of which depends largely on the effective management of change needed for the successful adoption of this new product. By themselves, products do nothing. When that product is used it causes changes that are termed outcomes. Measured outcomes are benefits that add value through improvements.
- Realise Benefits (also dis-benefits and costs) that may be one-off or repetitive, financial or non-financial, immediate or longer-term, direct (primary) or indirect (secondary), expected and unexpected, and possess different likelihoods of realisation. Thus, a project doesn’t end when the deliverables have been produced; the project ends and is deemed successful, when benefits have been realised. Here are four examples of products with their intended outcomes and benefits:
- – Product A: New order processing software installed. Outcome: Faster processing of customers’ orders. Benefit: Reduce the average processing time for customer orders by at least 20% from the current average of 15 minutes.
- – Product B: Sales campaign revitalised. Outcome: Attract new customers. Benefit: Add a minimum of 20 new customers each month for the next year.
- – Product C: Website updated. Outcome: Attract more viewers. Benefit: Increase visitors to the website by an average of at least 5% each week for the next year.
- – Product D: Core values published. Outcome: Enhanced culture, morale and image. Benefit: Staff absences and turnover reduced by at least 30% during the next year.
To help with benefits realisation, some useful practices are to ensure:
- That the business case clearly identifies anticipated benefits.
- That business case reviews are scheduled to validate benefits.
- That stakeholders who will be affected by each benefit are identified.
- That outputs and outcomes required for the realisation of each benefit are identified.
- That measures are in place for each benefit.
- That responsibilities for delivery of benefits are assigned.
- That benefits are prioritised according to their anticipated positive impact.
While a project is a benefits-led initiative, some facts about this are these:
- Immediate project success, rewards and recognition are usually measured in terms of project objectives (scope, time, cost and quality) and not whether products yield their intended benefits. Thus, a PM could deemed successful, but a BA unsuccessful, or sometimes visa versa.
- Most organisations have no formal process for managing benefits. Like their project managers, the organisation is often preoccupied with producing products, while benefits are left to chance. In fact, projects are invariably named after their products.
- Benefits realisation is probably the most ignored area of project management except perhaps at the start of a project when sponsors or BAs might highlight or even exaggerate the anticipated benefits of project propositions and downplay the costs to help get projects approved. As a consequence any benefits management regime is then built on unsafe foundations.
- Benefit realisation has become a vital driver for projects and it is increasingly common to assess the success of a project by achieved benefits rather than evaluating success based entirely on the traditional measures of time, cost, quality and scope.
- Post Implementation Review, which recognises that true success is about realising business case benefits. However, sometimes benefits are not realised for these reasons:
- – An unsatisfactory business case that doesn’t properly identify benefits and/or over-states benefits, which occasionally might be deliberate to help ensure a project’s approval.
- – Requirements were constantly changing, vague, wrong, or excessive.
- – Little thought given about the benefits that the products are intended to create.
- – Product users aren’t properly trained in the use of the new product, have no or little buy-in, and/or are reluctant to make the necessary changes.
- – Believing that the project is over once the final product is produced, expecting benefits to automatically occur without further effort, or expecting benefits when there’s been no change.
- – Changed external factors diminish or cancel anticipated benefits. Such external impacts are more likely and significant when benefits are to be realised over a period of years rather than within weeks.
Outcomes are the results of the change caused by integrating the new output into the operation of our own or our client’s business. Such change needs to be managed to ensure that planned benefits emerge.
Benefits are measurable improvements or positive impacts resulting from outcomes and are perceived as advantages by one or more stakeholders, such as a reduction in business costs by say 10% over the next six months, or an increase in sales by say 15% per annum. Benefits answer the question “What value is derived from this outcome?” and should be supported by key performance indicators (KPIs).
Post Implementation Report. The post-implementation report is usually prepared by the BA for the project sponsor once the project product has been implemented into business-as-usual routine and assesses the extent to which anticipated benefits and disbenefits have been realised. This benefits review focuses on measuring the success of our project by measuring and evaluating the operational impact of the project product generated as a project outcome. The report describes the transition of the product to operations and should include any difficulties or challenges faced during this period of change. The report should also highlight what went right during the transition so that future projects may reference and use best practices to improve project performance. The report would also have a title page, a distribution list, an amendment record and a contents page. “Reader-friendly” is an important principle.
|Summary||A quickly read version of the report – purpose, main findings, main conclusions and key recommendations.|
|Introduction||Identify the product and provide a brief description about the product’s transfer to operations.|
|Report Purpose||To assess the product’s performance and benefits realised.|
|Key Questions||• Did the project solve the problem that it was designed to address? • Are the anticipated business benefits being realised on schedule? • Have any unanticipated benefits been identified? • What has been the magnitude of disbenefits? • Can we deliver further benefits? • What is the level of user satisfaction? • Was user training adequate and timely? • What are the product’s strengths and specific areas of success? • What are the most frequently used features and functions? • Which features and functions are used least? • What features are not used at all? • How might the product be improved – possible enhancements?|
|Variances||Identify and explain any significant variations between actual results and expected benefits and costs.|
|Outstanding Issues||Sometimes there are outstanding issues concerning on-going product training, use, repair and maintenance, and enhancements.|
|On-going Support||Provision of on-going product training, use, repair and maintenance, and enhancements.|
|Lessons Learned||Identify any lessons learned that can be used to improve how future projects and product perform.|
|Conclusions||These are the result of the evaluation and follow logically from the above analysis.|
|Recommendations||What recommendations follow from the report’s conclusions? Might be product enhancement projects.|
Check here for the BABOK, guide to the Business Analysis Body of Knowledge Version 3, 2015, IIBA, the Institute of Business Analysis.
Check here for the PMI Business Analysis for Practitioners – a Practice Guide, 2015.