Analyse this User Story:

“As a Data Analyst, I want an anonymised copy of our 2025 sales data, so that I can use it for customer research without risking exposure of individual identities.”

While this may look like a well-written User Story that follows the INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable) criteria, there is some ambiguity that carries potential legal, ethical and reputational implications.

Whether we use AI simply to assist with some of the tasks or we have a sophisticated AI tool that can process and output the anonymised data, any ambiguity that is not clarified may lead to unintended results.

Analysis

Anonymise – Wouldn’t simply obscuring or removing the customer names from the data make it anonymous? Well, technically, and by the definition that AI understands, yes. But what if the data includes addresses or phone numbers? Wouldn’t that potentially still reveal someone’s identity?

So to be safe, why don’t we just remove all personal information? Yes, that’s possible, but what if our research needs to identify statistics based on customers’ postcodes / cities / countries?

These are all questions that good a Business Analyst needs to ask when eliciting requirements from the stakeholders. The good news is, such elicitation techniques can be learned, and as with many things, the more you practice the better you become.

Ambiguity in Requirements Documentations

And don’t forget, in the requirements lifecycle, requirements elicitation is only one link in the chain. After eliciting the requirements, you still need to document them so that the requirements can be implemented, tested, deployed, used and supported.

As we know, and as we can see from the example User Story above, the English language is prone to ambiguity. That’s why good requirements documents often include visual artefacts, such as BPMN diagrams, data models, Use Cases, Decision Trees, etc. The structured nature of these artefacts allows you to efficiently describe processes, data flows and rules with minimised risks of misinterpretation, by both humans and AI tools.

Become an AI-Ready Requirements Expert

• Business Requirements Elicitation
• Business Analysis Accelerated
• Business Process Modelling
• Writing Better Requirements

– Browse all Business Analyst Courses. –

The post The Risks of Ambiguous Requirements in AI appeared first on IRM Training.

Why Should a Business Analyst Hold an Interview? 

The first purpose for an interview would have course be to explore the existing system. This is usually the first thing we have to do when beginning a new project, that is to understand the existing system which will be replaced by a new one or enhanced in some way.

Other contexts may be to define the business goals and objectives of the project, or to drill down and understand the project contexts and the conditions under which it will operate in more detail.

A business analyst will always want to understand processes, procedures and structures that are in place in an existing system. Alternatively, the analyst will seek requirements for the new system within the constraints under which it will operate.

Experienced business analysts will also look for the informal information flows and collaborations that occur between the users, because these can be the most crucial requirements of all. Not everything will be automated by the existing application, or the new solution once it is implemented.

Outside of this automation boundary there will be interactions that occur between people, often ones which are not documented. The analyst needs to understand how the people work as a team, not just how they interact with the system.

What Can an Interview Do For a Business Analyst? 

The interview is not just to elicit facts and figures or to develop process models, they can also be to establish the opinions and beliefs of the people who will use the system. These can often be more important in revealing than the facts about the system itself.

Never underestimate the importance of people’s feelings about the existing system or their wishes for requirements in the new system. These can have emotional value to the people. We need to understand the morale and culture of the users. We need to capture their emotions and attitudes. In this way we will begin to understand the type of solution which would be successful for them, in their environment and within the context of their team culture.

The interview will also define the goals of the stakeholders and what they need from the new system. It will define their desires for the future and the direction they want their team, department or the organisation to follow.

A crucial element of the interview is to also build up a relationship with stakeholders, and establish their trust. It is possibly the most important thing to do. Unless the users believe that you are interested and committed to finding the best solution for them they will not trust you with their future. The credibility of the business analyst is a most important factor to the success of the business analyst.

Communicating with the Interviewee

The most important factor in the success of the interview is of course the interviewee. The business analyst needs access to their knowledge and skills. They are the ones who know what the true requirements are to ensure the success of any solution.

Business analysts are there to provide communication between the users and IT. They should understand that users can be intimidated by IT, and the business analyst should behave sympathetically to their feelings. Any change can be fearful to the users, and the business analyst should behave in a way that is sensitive to their potential fears.

The interviewee can be motivated by their fears and needs on one side, but also by their hopes and ambitions on the other, and above all by the need to be understood. They want to know how any changes will impact upon their job, responsibilities, influence and even power. Senior managers will be concerned about their power base. Professionals and more junior staff will be worried about job satisfaction, and ultimately job security.

Maslow’s Hierarchy of Needs in Interviews

Business analysts need to have an understanding of the way in which people’s beliefs and needs operate within their minds. One model for understanding this is called Maslow’s hierarchy of needs. This is illustrated by the pyramid in the diagram.

The pyramid illustrates begins with basic survival at the bottom, through to our highest aspirational needs at the top. At the bottom we can see the need for sustenance. This is the basic need for good health and a basic salary which will enable us to live comfortably. This is the minimum in a modern society.

Above this, we would like stability. No one likes change unless we are initiating the change and can control it. We desire security and confidence in the future. We dislike the unknown. We would like to know that we have the future planned out. This can work out in practice as, for example, having a superannuation plan.

Once we have the basics met, then we want to know that we are valuable and are making a contribution. Friendship and belonging are measures of that self-worth. These can work out as being part of a working team or group of friends.

Our esteem can be fully met when we believe we are respected and have status within our situation, either at work or among our friends. A practical example would be a senior job title which demands respect.

The ultimate need is to know that we have achieved our dreams, or have a challenging job, or completed a task which was very difficult. These confirm our highest aspirations.

Communicating with Different Kinds of Interviewees

Now let’s consider what happens during the interview with the interviewee. The business analyst should be aware of the body language, the dress code, behaviour and verbal language of the interviewee. These are ways to understand their desires, their needs and even their agendas.

Be careful not to stereotype people by these parameters. Some anxiety during an interview is common and should not be thought of as a permanent feature of their personality.

The business analyst should adjust the approach to the interview according to what is detected. Impatience and anger should be dealt with tactfully, but firmly because we still have a job to do. Anxiety and fearfulness should be counteracted with friendliness and reassurance. If the interviewee appears to be dishonest, misleading or to have a hidden agenda, then the business analyst should be asking questions more closely and confirm any answers from another source where possible.

Combating Interviewer Bias 

The interviewer should be aware of their own biases and preconceptions of the situation and not allow them to interfere with a neutral attitude to investigating what the true requirements are. To be biased will prevent the business analyst from gathering the true requirements, instead of the requirements they believe the user wants. These will inevitably be incorrect.

Sources of bias would be the business analyst’s education, upbringing, intellectual attitudes and emotions. Being professional at all times will ensure that a good attitude will deduce the real requirements that are needed to provide the correct solution to the users.

How to Act in a Business Analyst Interview

The interviewer should understand and adjust to the interviewees personality and motivation. They should endeavour to win their confidence, respect and ultimately their cooperation. As we’ve said already it is imperative that the users have confidence in the business analyst and the job they will do in documenting their requirements, needs and aspirations. They are trusting the business analyst with their future.

The business analyst must actively listen to the user and know what they are actually saying. They must not impose their own judgements or beliefs on top of what the interviewer is actually saying. It’s imperative that the truth about what the user is saying comes through in the requirements. Otherwise the business analyst will fail and the requirements will be rejected by the users and not signed off.

Preparing a Business Analyst Interview

What to do Before the Interview? 

So let’s have a look at a few steps that should be followed by the business analyst before going into the interview.

The first step is always to examine existing documentation where it exists. Look for the language and terminology used by managers and stakeholders. Try to build a common understanding of the current system, processes and environment in which users operate. It will help to build relationships and establish the confidence of the users, if we show that we already have some knowledge of their situation and can accurately use their jargon.

Be careful not to use their jargon unless you truly understand what it means. It can be very embarrassing when you are picked up for use in a term incorrectly. Users often believe everyone understands their terminology.

Second step is to define the objectives of the interview. There is no point setting up a meeting unless it has an objective and success can be measured, so that we know when we have achieved what we set out to do.

Establish in advance who are the correct people to interview. The business analyst at this point should halve developed an understanding of who the key users of the system are, and who has the most complete knowledge of the requirements.

Consideration should be given to those who seek to impede the project, and a strategy should be developed as to how to deal with them. They should not be ignored, because they can justifiably complain that their requirements were not taken into account. Equally their opposition should be taken into account when interviewing or interacting with them in any way. They must be included in the analysis process.

Preparing to Interview Stakeholders 

The next step is to prepare the interviewee for the interview. The best way to allay their fears or their opposition is to inform them of the objectives and expectations placed upon them in advance. Once they understand the interview will take place and why it must take place, give them time to think about how they will approach the interview so that they can define any issues they have in advance. That way they can have confidence that they can make a contribution to the interview.

The final step is to decide what type of structure to give the interview. For example, do we need to ask open questions which will elicit opinions, ideas and potential issues. Alternatively, are we just after facts and figures and should be asking closed questions which have short definite answers. Should the interview be highly structured because it’s a formal meeting, or can it be conducted in an unstructured manner even over a coffee.

Open vs Closed Questions for a Business Analyst Interview

Pros & Cons of Open Questions

This brings us to the question of open and closed questions and which to use.

Open questions are used when we do not know what the answer is likely to be. When we want to obtain rich detailed explanations of how the system works, to reveal the needs interests and opinions of the users in detail. When we want to pick up vocabulary beliefs and values of the interviewee. They also help to put the interviewee at ease allowing them to express themselves in their own way.

The disadvantage of course is that we will get some details that are irrelevant, we lose some control over the interview and they are more time-consuming. However, it is often necessary to accept these disadvantages.

Pros & Cons of Closed Questions

Closed questions are used when we know there are only a few valid answers and we need to know what the definitive correct answer is. For example, where the answer is a definitive yes or no, or where the answer is a single number.

The advantages of closed questions are that they are quick, they allow us to control the interview, all the detail is relevant and it is easy to compare answers with other interviewees. The disadvantage here is that they do not provide the rich data we might need, highlight key issues we might not be aware of, they do not help to build rapport with the user and can be quite boring.

Questioning Techniques for a Business Analyst Interview

There are some rules that must be obeyed when we ask questions. Always use probing questions to elicit the answer that is needed.

Always avoid leading questions that suggest to the user that we want a certain answer, or that a certain type of answer is the correct one.

Always go prepared with a list of questions to be asked. This enables subjects to be tackled in logical order. It also avoids long silences when we reach the end of a topic while the business analyst is thinking of what the next topic should be.

A useful technique to ensure that you have all the detail and have understood it, is reflection. To do a reflection you repeat the answer back to the user to make sure that you have understood it correctly. For example, we can say, “Let me make sure I have this straight. You send an email to the client, then…”.

Structured vs Unstructured Interviews

Let’s have a look at structured and unstructured interviews.

Structured interviews are very formal with all questions planned in advance. The same wording and word order is followed, very formally and all interviewees are asked the same questions.

Unstructured interviews cover general topics of discussion. They may be planned to some extent but not as rigidly as a structured interview. The order and wording of questions is not rigidly planned. There is more scope for allowing the user to express themselves in their own words.

Structured interviews tend to be used with senior managers who expect certain behaviours and processes to be followed. Unstructured interviews are more common with junior users who actually use the system and have detailed knowledge we seek.

What Not To Do When Conducting An Interview

This slide might seem obvious to anyone who has worked as a business analyst before, but it must be said. There are certain things we never do as business analysts conducting an interview. We do not argue with the user, lose our temper, appear to be superior to them in any way, criticise their answers or enter conjecture into their answer. These are simple things to avoid which can expose the business analyst as being unprofessional, and can disrupt the relationship with the stakeholders.

Do not use inappropriate jargon, such as complex IT terminology. This can intimidate the user.

An essential practice is not to move on to another topic until you have fully understood the current subject. It can be difficult to return to the topic later with the same user.

Finally, it is essential never to assume that we are getting the whole truth from a single user. Answers should always be corroborated from more than one source wherever possible.

Wrapping Up Interviews 

To complete our webinar today let’s just recap some of the golden rules that we’ve discussed in our travels.

Don’t believe everything you told, but corroborate everything that you are told against another source if possible.

Reflect back the main points to the user if there is any doubt about understanding exactly what was said.

Finally, at the end of all interviews, the business analyst should send an email or some kind of communication to the interviewee with notes about the main points that were discussed. This has two purposes. One is to give you the confidence that what you have gathered as requirements is sound. The second is that even if the requirements do not have to be signed off, the interviewee cannot change their mind later and claim that that is not what they said. The email acts as a confirmation of what was said even if no signoff his required. It gives some protection to the business analyst that the requirements are accurate, and cannot be denied by the interviewee later.

The post Business Analyst Interviews appeared first on IRM Training.

What Is Agile?

There are many definitions given for Agile. The one we have selected, is the one provided in Wikipedia.

“Agile software development describes a set of values and principles for software development under which requirements and solutions evolve through the collaborative effort of self-organising cross functional teams”.

Notice first of all that it is concerned with values and principles, rather than a new technique which we can learn from a textbook. We must first regard the culture and purpose for which Agile was designed before we can begin to use it, otherwise it does not make sense.

It is primarily concerned with how people collaborate and interact, to develop software. It is very much a human-based development. There is also a large amount of trust involved in Agile. It depends upon self-organising teams made up of different disciplines and professions being able to interact successfully to achieve results.

History of Agile

Agile was originally developed in the early 1990s in response to the apparently rigid and inflexible Waterfall methodology. A group of programmers gathered together and came up with a manifesto which concentrated upon flexibility and human interaction as the basis of software development. The manifesto is quite detailed but is summarised in a small number of principles as we have in this slide.

People and interactions between them are considered more important than the processes and tools followed mechanistically in the waterfall methodology. Collaboration with the customer is considered more important than dry contract negotiations, which do not help to build a relationship with the users.

It is more important to be able to respond to change rather than mindlessly following a predefined plan. The product is considered to be working software rather than written or graphic documentation.

In other words, it is more important to form a relationship between the members of the team and the customer or stakeholders, than to stay at a distance and simply operate through a legal contract with them. It is more important to be flexible and responsive to changing conditions that affect the project, rather than following a plan some would say mindlessly. The product is the software itself which is considered to be far more important than the documentation.

The Agile Manifesto

The Agile manifesto was published in 2001 based upon 12 basic principles. We do not have time to discuss them in detail here, and you are free to explore them in more detail later, however we can mention a few highlights.

You will see highlighted consistently words like customer satisfaction, cooperation, motivated individuals, face-to-face conversations. These are all words about people successfully interacting while they work towards a common goal.

Principle 2 welcomes changing requirements instead of resisting them as you would find in the waterfall methodology. It expects them to occur throughout the project life-cycle.

Working software is mentioned as the only valued product in several principles. Technical excellence, good design, best architecture and simplicity are mentioned in several principles. The team is expected to be self-organising and to be constantly adapting to change.

Waterfall Revisited

Before we dive deeply into how Agile works, we need to revisit our concept of the Waterfall methodology as the commonest example of existing software development methodologies. It consists of a series of separate stages carried out in sequence with very little opportunity to overlap. In other words, they must be carried out in the correct sequence. One stage cannot be started until the previous stage is completed and signed off. There is very little opportunity for overlap between them.

If an error is detected, it is very difficult to call back and redo a stage. The project could split off another project if extra requirements were detected. Alternatively, if the change is too great or critical, the project would be stopped, re-scoped and started again to accommodate the change. The deadline and the cost would be reconsidered from scratch because of the new or changed requirements. It is unlikely these changes will result in a shorter deadline or reduced costs.

Scrum Project

Let’s consider what Agile actually looks like on the ground. There are many forms of Agile methodology currently in use and published, so for convenience we have selected the most popular one in use locally, which is Scrum Agile methodology.

In the diagram we see an example structure of a Scrum project. It begins with the scoping of a product backlog which is the functions expected to be performed by the software produced. This is equivalent to the project scope in waterfall terms. It is defined as a collection of small atomic functions or software units that can easily be developed in a short period of time by a dedicated team. These functions are prioritised and built in triage order.

The project then consists largely of series of short development cycles called iterations or sprints which can typically last from between 1 to 6 weeks. Most common sprints last 2 to 4 weeks. During the sprint the development team agrees to develop a collection of functions or software units by the deadline. The project is time boxed which means that the deadline will not change. If there are delays or the team can develop the sprint backlog more quickly they will develop less or more than agreed, but the deadline will not change. Once the sprint is over and the deadline reached there will be a review of what has been developed within the sprint. That will dictate what is agreed for development in the next sprint.

There are daily meetings often called stand-ups, where every team member states what they have achieved in the last 24 hours, what they intend to do in the next 24 hours, and any impediments or problems they have encountered or expect. There will then be discussion after the meeting around how impediments and problems can be circumvented. The meeting itself is intended for a fixed agreed time, in other words it is also time boxed. Any issues are handled after the meeting, but the meeting will finish on time. Typically, a stand-up lasts 15 minutes for the normal size of development team.

Scrum Framework

The Scrum framework is illustrated in the diagram below which consists of an end to end process for the Scrum Agile methodology.

The process begins with inputs from the end users, stakeholders, team members and customers to the Product Owner who is the custodian of the requirements. The Product Owner is responsible for compiling the scope in the form of a product backlog. This will be the scope for several Scrum sprints or iterations.

The project team is a multidisciplinary collaborative team. It is their responsibility to prioritise and select the functions from the product backlog which will be developed in the next sprint. They develop a subset of the Product Backlog for one sprint which is simply called the Sprint Backlog.

They then undertake the sprint which will run from 2 to 6 weeks and end on the set deadline. The team will work at a steady sustainable pace to develop the functionality in the sprint backlog by the end of any sprint as it has been agreed. The end result will be functions in the form of executable software that can be released to the user’s customers and stakeholders via the product owner. The product owner is responsible for ensuring the testing and verification that software released will be of value to the business and will function correctly.

As we’ve said there will be daily stand-up meetings to review what each person in the team is doing each day what they’ve accomplished previously and any problems that they have found. The team will be responsible collectively for resolving any problems found. At the end of each sprint there will be a Retrospective meeting which will review the sprint and lead to other meetings which will determine the scope of the next sprint. The next sprint will be decided based upon the next sprint backlog compiled by the team.

The meetings held regularly or at each stage in the project are called ceremonies. These are used to initiate and terminate sprints or projects and to regularly monitor progress.

The Scrum Organisation Structure

The Scrum development team is referred to as the Scrum core team. It is made up of three types of role. The first is the Product Owner. This role is responsible for defining the product backlog and ensuring that it is developed in order of priority. The Product Owner communicates with the customers or stakeholders gathering requirements from them to define the product backlog. At the end of a project or a Scrum the Product Owner is responsible for delivering value to the customer in the form of product releases of working software.

The Product Owner also communicates the requirements to the rest of the Scrum core team.

The Scrum Master ensures that there is a problem free working environment for the Scrum team itself. It is the Scrum Master’s responsibility to resolve any problems or impediments that would hinder the sustainable development process of the Scrum team.

The Scrum team is made up of developers of various disciplines. It is the Scrum team’s responsibility to agree the functions that will be delivered in the next sprint. They are self-organising and do not follow the dictates of a project manager. They work together to resolve problems and deliver working software within each sprint, which delivers value to the stakeholders. If they encounter difficulties they are supported by the Scrum Master, but also adapt the way in which they work so that problems and issues are resolved by the team themselves.

The optimum size for a Scrum Team from 6 to 10 members which is large enough to ensure adequate range of skill sets, but small enough to collaborate easily.

Empirical Process Control

We mentioned earlier that Agile depends upon people following the principles laid down by the Agile methodology. One of the underlying principles of the Agile methodology is empirical process control which is based upon 3 main ideas. The first is that all tasks will be performed transparently so the entire team is exposed to everything that’s going on. If any team member has difficulty delivering their functions the whole team is responsible for resolving those difficulties and ensuring that the team delivers.

Transparency is maintained by incorporating the practice of continuous inspection into the software development process. Not only is the software tested, it is also inspected by the entire team to ensure that the software delivered is according to best practice and the highest quality possible.

The third principle is adaptation. We have already seen that changes are expected and welcomed as part of the development process within an Agile environment. When change does occur, the team adapts to the new requirements and constraints and works in a new way to ensure delivery of the software product.

Kanban

Many people have heard of the Kanban wall when they hear about Agile projects. In practice this is an optional tool for monitoring progress. The Kanban methodology has introduced it to Agile, and it is typically adopted by many other types of Agile project including Scrum, but it is optional.

There are electronic tools that can be purchased to maintain the Kanban wall online such as Jira or Trello. Most commonly projects maintain their Kanban wall physically using post-its on a whiteboard or wall within the office. Columns represent different statuses of development of functions within a sprint. There are typically columns for the sprint backlog, the product backlog, functions in development, functions in test and functions delivered. There are many variations upon the Kanban wall but all typically cover some of these common statuses.

Challenges of Implementing Scrum

When Agile or Scrum is introduced to a new organisation there are several challenges which typically arise that must be overcome. The introduction of Agile is a major change to the way in which the organisation works. It cannot be introduced in a single day and must be introduced using a professional change management process. Let’s examine some of the issues that arise during the introduction of Agile.

To begin with the introduction of Agile demands a degree of trust that the Scrum team will be self-organising and able to work together by mutual agreement and collaboration. This runs contrary to what many managers who have been taught all their lives that people will only work under close supervision of a superior manager. To enable employees to organise themselves and ensure that they are working hard and pulling together demands a change in culture and management methods.

The project management office will operate differently and project budgets will be far more progressive and flexible than they were before. The Waterfall method advocates that the budget should be set at the beginning of the project and it should not change if there is no change in scope. Agile expects change and therefore the budget and scope will constantly change throughout the project. Project estimation will be repeated throughout the project life-cycle instead of being estimated at only the beginning as it is with the waterfall project.

All of these changes will demand a change in culture and the way people work which will require a gradual introduction of the Agile methodology across the company. Many companies are trying out Agile as a proof of concept or in a certain part of the company, usually within the IT department at first. Others are further down the track and are considering introducing Agile across all departments of the business not just in IT.

Agile Professional Development

Before we finish we need to consider how business analysts can get into the Agile methodology and become trained and equipped to operate inside an Agile project, either as a Product Owner, Scrum Master or part of the Scrum team.

The entry qualification for most people is to pass an exam as certified Scrum Master or certified Product Owner. This is the entry level qualification for a business analyst or project manager to participate in an Agile project. In Scrum there is no role for a business analyst or project manager. There are no such formal roles. Therefore, business analysts and project managers will see their job descriptions change radically as they assume one of the roles that we’ve seen in Agile or Scrum project team.

The next steps are to be trained and certified in the application of Agile to larger projects and programmes of work. The first is the Scaled Agile Framework or SAFe® framework. And the final step is the Large Scale Scrum or LeSS for short. These constitute the application of Scrum Agile methodology to the larger scale. It can be said that the large-scale Scrum is more about what you don’t do on Scrum projects rather than what you actually do.

Thank You

Thank you for listening to a webinar on this topic. I will be happy to take any questions at this time. If you think of any further questions after the webinar has concluded, please send an email and we will endeavour to provide an answer to your questions or make a comment in reply to your observations.

We hope you’ve enjoyed this webinar on agile business analysis and will join us for future webinars. Thank you.

To learn more and get certified please see our Agile courses page.

The post Introduction to Agile (and Scrum) appeared first on IRM Training.

We conducted a survey of over 1,100 business analysts (68% with over 5 years experience) which gave some interesting results as to what business analysis techniques are the most popular.

Methodologies

When it comes to software development methodologies, 68% said they had experience with waterfall development, 46% said iterative whilst object-oriented (44%) and agile (34%) also rated highly.

Assuming that many of these analysts would be working for large organisations – with mainframe systems – it’s not surprising to see waterfall so widely represented. We can also conclude that analysts need to work on a variety of different applications – iterative, OO and agile being very common on web services and client/server projects.

Interestingly, disciplines like ITIL and Six Sigma, which have received lots of press recently, only rated 20% and 17% respectively.

Modelling

Whilst the most regularly used diagramming technique was flowcharting (63%), when it comes to formal diagramming techniques, use case led the way (55%) followed by data flow diagrams (42%), activity diagrams (38%) and context diagrams (34%). Entity relationship diagrams were still widely used (30%) and “new kid on the block” BPMN came in at 13%.

Note that Business Process Management (BPM) scored highly in the methodologies section (52%) but didn’t show a correspondingly high result for BPMN usage. Perhaps this indicated that BPM was interpreted as a generic term covering methodology, software products and general process improvement?

Elicitation

For requirements gathering, 67% said interviewing was the most frequently used method. Requirements workshops came in at 45% and JAD sessions 34%.

The survey showed there were a bewildering range of tools, techniques and methodologies in widespread use. Probably too many for the poor analyst to master. As always, it comes down to the old saying – it’s not what you know it’s how you use it!

Download our free Requirements Specification Template

If you liked this article, you may also enjoy:

Facilitated Workshops – When and Why?

There’s More to Modelling than Runways & Catwalks

Creative Thinking Techniques

The post Most Popular Business Analysis Techniques appeared first on IRM Training.

The reality is, the more sophisticated the software you’re using, the greater the chance it will hinder, rather than help, the business analysis process.

Almost 10 years ago, an article by Scott Ambler, Software Modeling on Whiteboards, argued that the modelling tool with the greatest installed base in the world was the whiteboard. Scott is the agile practice leader at IBM and author of several books on agile and UML.

Similarly, Alistair Cockburn (of Agile Manifesto fame) put forward in his 2001 book Agile Software Development that face to face is the most effective form of communication – particularly when enhanced with whiteboards, flip charts, paper or index cards. See Scott Ambler’s article on Communication on Software Projects which uses data from Alistair’s book.

Ok you might argue, but the world has moved on, smart phones, tablets, cloud computing are not only part of our everyday life but essential to it. We now have a huge range of modelling and requirements management tools at our disposal.

So why have recent business analysis articles trumpeted the benefits of such leading edge business analysis tools as Etch a Sketch and drawing paper? And we all know that agile was really invented by 3M as a means of boosting post-it note sales!

In the words of Brian Cooney, author of Separating Analysis from Design, would Shakespeare have been a better writer if he had a word processor? If you think so, grab your favourite word processor and write a sonnet which people will be delighted to quote 400 years from now.

What’s clear from all this is that the best business analyst tool in the world is the one you’re born with – your brain. Mastering it and applying its enormous capabilities to your business analysis problems is a far better ROI than learning the latest software toolset.

Download our free Requirements Specification Template.

If you liked this article, you may also enjoy these:

Business Analysis Basics

Most Popular BA Techniques

Stakeholder Communications – Pictures not Words

The post Is Business Analysis Low Tech? appeared first on IRM Training.

To understand this we need to start at the beginning – or rather at the top. Everyone knows a company’s objective is to make money (if we’re a commercial organisation) or to provide services to the community if we’re in the public sector. This is what we do, but to appreciate our role as business analysts we need to understand the link between what our organisation does and how it’s achieved – and how the little things we do fit into the big picture.

Do mission statements clarify or confuse?

We’ll start with mission statements as many people think they describe what an organisation does. Others assume it describes how the organisation operates, while some believe it describes the organisation’s values. In fact a mission statement can be all of these. Look at the following examples:

• Put the needs and well-being of the people we serve first.
• To help people and businesses throughout the world realize their full potential.
• Deliver sustainable, satisfactory returns to shareholders.
• To inspire & nurture the human spirit – one person, one cup & one neighbourhood at a time.
• Assisting people to become self-sufficient and supporting those in need.

Five mission statements, one is telling us what the objectives are (to make a profit), others are telling us how they plan to achieve their objectives, and some are telling us the corporate values they adhere to whilst pursuing their objectives. These examples come from a mix of private and public organisations. Which do you think is which? i It’s easy to see how any of these could confuse us as to the organisation’s primary objective. The harsh reality is that commercial organisations are here to make a profit – no ifs, buts or maybes. They can still do this ethically and morally but if they don’t make a profit, they’re history. Being clear on objectives, both at the corporate and project level, is critical for a business analyst and we’ll revisit this issue once we’ve had a look at how organisations go about doing what they do.

Organisations only do two things

So how do organisations go about doing what they do? We can explain this by understanding that every organisation (private and public) has both an operational side and a project side. Operations is the “business as usual” component, supplying goods and services to consumers, businesses or the community.

Of greater interest to the business analysts, in fact our raison d’être – our reason for being – is that no organisation stands still, they are all moving some part of their operations from an “as-is” to a “to-be” state – from a current to a future state. In some organisations this movement might appear glacial, in others frenetic, but every executive knows that if you stand still then you end up going backwards. The competition will overtake you (commercial sector) or the efficiency of your operations will fall behind best practices, cost more and become the subject of inquiries and audits.

Projects change organisations

To move from where you are today to where you want to be tomorrow requires a project – a planned activity to achieve specific objectives. The vast majority (if not all) projects occur in order to achieve one of the following objectives:

1. Meet legislative, compliance, governance or safety obligations
2. Lower costs
3. Increase revenue and/or profits and/or market share
4. Increase efficiency
5. Improve quality

Note that projects which improve, say, customer service or increase customer satisfaction are not objectives in themselves, they are a means to an end (point 3 above). In the same vein, projects which lead to a competitive advantage or address a competitive disadvantage are only undertaken in order to address the third point.

To look at similar examples in the public sector, providing a self-service portal on a government website can be a mixture of point 1 (enacting government policy) and point 2 (getting best value out of tax payers’ dollars).

How projects work

The vast majority of business analysts work on IT related projects where the development or procurement of software is a central component. In the same way that most projects fall into one of the five categories mentioned above so most software intensive projects are delivered using just a few methodologies.

A 2010 global survey of business analysts conducted by International Institute of Business Analysts (IIBA®)/Forrester Group ii reported that the three main methodologies in use were:

• Waterfall (34%)
• Iterative (9%)
• Agile (9%)

More importantly though, 45% used a mixture of some or all of these. This might not sit well with proponents of one methodology over another but it tells us that the best tool for the job is the one that gives the best outcome – not the one that’s flavour of the month. So does a business analyst need a split personality depending on the type of project? Do they need different skill sets from one project to another? Definitely not, if they keep in mind what the objectives of the project are.

Why business analysis skills are timeless

All projects exist to achieve an outcome, regardless of the development (SDLC) methodology. Every project will have scope, boundaries, sponsors, constraints……and requirements. Some of these will (hopefully) be nailed down e.g. the sponsor. Some may be fluid and evolve over time e.g. the requirements. But all of them will need somebody (the business analyst) to conduct interviews, facilitate workshops, investigate problems and objectives, validate and verify information. The analyst will have to make sense of this and make sure that the developers – the solution providers – understand it.

There’s a good reason why books like the Business Analysis Body of Knowledge (BABOK®) – and the Project Management Body of Knowledge (PMBOK®) before it – have become the definitive reference guides for their profession. It’s because the techniques and skills they describe can be used on a vast range of different projects.

Just look at some of the underlying competencies listed in the BABOK® – analytical thinking, problem solving, communications and interaction skills, business knowledge. Can you think of a project methodology – or business problem – where these sorts of skills aren’t essential?

Of course the techniques you use will vary from project to project. For example you won’t need to conduct a formal interview when you’re co-located with the business user (on an agile project). But you will still need to ask the right questions to understand their business problems.

Being objective about objectives

All projects ultimately boil down to two business objectives:

• Making a profit
• Reducing costs

In fact for commercial organisations it boils down to one – making a profit. The other objective – reducing costs – is just another way of increasing profits.

For government organisations the focus is on minimising costs whilst meeting legislated obligations. At least that’s the assumption – we hope they’re not out to make a profit!

As a business analyst we would be overstepping the mark to criticise a project sponsor over their business objectives. However we still need to understand where the project we’re working on fits in the big picture. Quite often the business analyst will be involved in writing the project objectives and this is our opportunity to question – perhaps challenge – any and all assumptions that have been made about the project’s business benefits.

We can start by revisiting organisational objectives – make or increase profits, reduce costs, provide legislated services – and see how they map down into project objectives.

For every organisation, 99% of the projects they undertake will fit one of these business objectives. For any project we might be working on, one of these objectives should feature prominently in the project charter or terms of reference document. That’s our clue that the project is aligned with organisational objectives.

What’s going on in the marketplace?

For those business analysts working in a commercial organisation it’s also necessary to understand where your company sits in relation to its competitors. Is it:

• A market leader wanting to maximise market share
• A market leader wanting to maximise profits
• Operating in a mature market where customer service is the differentiator
• Operating in a mature market where lowest costs are the differentiator
• Expanding into new markets
• Trailing the competition and planning to catch up
• Trailing the competition with no real strategy!

It’s sometimes hard to appreciate these factors from within – isn’t it part of every manager’s job to motivate and inspire their staff? – but keeping an eye on the financial press, particularly industry reports, will give you another perspective on how the health of your company is viewed.

Making a profit vs. increasing profits

A final word on profits. For some organisations it’s not enough just to make money, they also need to increase profits. This may be driven by poor performance in the past or just a desire by shareholders to make more profit this year than they did last year. Put simply, profits are made by selling more than you spend. However to increase profits you need to sell more than you’re currently selling or spend less than you’re currently spending.

The second point is often easier to achieve but you can only cut costs by so much. At some point you have to sell more if you’re going to increase your profits. Whilst this is harder to achieve it’s the only path to sustainable growth – and the increased sales have to be matched by increased profits. Selling more – increasing revenues – by only reducing prices isn’t sustainable in the long term. It might look good on paper but to quote a well used saying: “Revenue is vanity, profit is sanity”

Private vs. public sector – not so different

This paper has used many examples from the commercial world to illustrate its argument. To those readers from the public sector who’ve made it this far, I apologise. Your job is no easier just because you don’t have to make a profit. You are still accountable to your senior executives and they in turn to politicians and the wider community. The community expects an ever increasing range of services – but delivered at an effective price.

So, in the end, there are many parallels between the public and private sector. You still have to give the community (customers) what they want or what elected governments (or visionary companies) believe they need.

Understanding the CEO

By now you should have a reasonably clear picture of what goes on in your CEO’s mind. Sure they have to provide vision and leadership – to set strategy and objectives. But like every manager they also have to manage upwards as well as downwards. Above the CEO is the board of directors who, in turn, are accountable to the shareholders. These shareholders expect a profit from their investment and this is what the CEO is hired to deliver. Vision, leadership, strategy and mission statements are how the CEO achieves this.

Download the full paper here: From Mission Statement to Business Process

If you enjoyed this paper, you may also like:

How Can I Add Business Value?

The BA’s Journey – From a Current to a Future State

What is a Business Analyst?

The post From Mission Statement to Business Process appeared first on IRM Training.