Tag: Methodologies

10 Best Business Analysis Books For Beginners

Written by Theresa Cofield on December 3, 2020. Posted in Articles. 1 Comment on 10 Best Business Analysis Books For Beginners

Corporate analysis is a discipline in which business requirements are defined, and solutions are identified for business issues.

For an organization to thrive and function successfully, some things need to be placed during its foundation. Here are some books that can be of assistance.

1. Writing Effective Use Cases (Agile Software Development Series) by Alistair Cockburn

Business analysts profit from case studies where they talk about how people use a system. This helps in planning projects and use cases is a crucial feature of business and software systems. The problem is that it is not so easy to write straightforward and succinct cases. Author Alistair Cockburn utilizes modern methods to write case stories in this novel.

You can learn about advanced principles that are useful, whether you are an experienced analyst or a novice. Cockburn presents strong and bad case examples to help you quickly and rapidly understand the difference. The main aspects of situations, like stakeholders, scenarios, etc. Design, moment tips, pre-built templates can be utilized.

2. Business Analysis Techniques: 72 Essential Tools for Success by James Cadle

Every analyst needs the necessary resources to accomplish the job. The work involves solving problems and exploring ideas. You need to know how to solve various types of problems, like identifying project specifications or handling changes.

This book describes these strategies carefully in order to help the reader deliver reliable results in business work. Think about it as a market analyst, a manager, or a student who is learning the trade, as a cheat sheet you can talk about.

3. Project Management Absolute Beginner’s Guide (3rd Edition) by Greg Horine

You have just started working as a project manager? In this book, you can easily and rapidly grasp key concepts by disrupting vital project management activities. You can learn how to organize and manage budgeting, planning, team management, and more. Each phase is outlined so that you can start right away.

The guidelines are simple and convenient. You will discover that the project managers make daily errors to avoid taking the same route. You can also understand what heading projects entail instead of merely overseeing them. If you do not know how to begin your job or your career, take this book to learn what you need quickly.

4. Project Management: A Systems Approach to Planning, Scheduling, and Controlling by Harold Kerzner

This is referred to as the Project Management Bible” since it offers practical insight into all facets of becoming a project manager. At all levels of a project, you can learn the techniques and methods to use. But it’s more than tips in this book. This text covers market changes, failure, agile project development, evolving industry topics, and project measurements.

There are just a few components that can limit performance in project management. This book is not a guide to project management, which is easy. There are plenty out there. When you want to know information about project management, quality assurance, and customer cooperation, this is the book you need to collect.

5. Business Analysis for Dummies by Kate McGoey, Kupe Kupersmith, and Paul Mulvey

Business Analysis (BA) is a group of activities that ensures that the company has the best solutions to achieve its strategic objectives. In order to carry out this workforce, it is important first to define the actual objectives and evaluate and propose solutions for a solution that needs to be addressed.

Provide guidelines as to how the market analysis will influence your company. Shows the tools and strategies to be a competent analyst. Provides many examples of how to market evaluations can be carried out irrespective of your position

6. Adaptive BABoK Study Guide by the Adaptive US

BABOK® summary graphically represented to enable simple, engaging learning of concepts and practices of business analysis. However, a visual presentation and a summary of this information are effective for you to learn. BABOK® guide includes a large amount of structured text information.

7. 3D Business Analyst by Mohamed Elgendy

Three distinct fields of 3D Market Analysis – business analyzes, project management (PM), and lean 6 sigma – with historically different skills and career paths. When, however, the components of these skill sets are analyzed and understood, a simple overlap is generated. When used together, they provide the BA with the required concepts, theories, and ends so that it can interact more effectively with stakeholders in its own language.

8. Agile and Business Analysis: Practical Guidance for IT Professionals by Debra Paul and Lynda Girvan

Agile is an iterative approach to software development that has quickly become the most common replacement for conventional project management in the IT industry. The use of an agile approach will revolutionize work practices for business analysts. It allows for a clearer vision and definition of performance steps, greater participation of stakeholders, and a better understanding of consumers.

This book offers an extensive introduction and discusses Agile methodologies in the sense of market analysis—ideal for companies wishing to learn and understand Agile Practices in an Agile Environment.

9. Business Analysis: Best Practices for Success by Steven Blais

A full overview of the business analysis method in addressing business issues is given by this book. This guide is also full of real-world stores from the author’s more than 30 years of experience working as a market analyst, full of tips, tricks, methods, and guerrilla tactics that allow the entire process to face often daunting political or social obstacles.

It offers strategies and advice to conduct a business analyst’s challenging tasks at times.
Authored by a professional in the sector with 30 years of experience.

10. Seven Steps to Mastering Business Analysis by Barbara A. Carkenord

Business analyzes are now the fastest growing sector in business and both strategically and tactically the position of the business analyses. Seven steps to mastering business analysis illustrate how all these variables, along with many others, are the secret to success.

This book offers insight into the ideal skills and features of good market analysts and is the basis for the learning process. This guide also allows you to prepare for enterprise analysis certification by describing the tasks and fields of expertise in the Knowledge Body.

Conclusion

Businesses form an important part of a state. Encouraging young people to venture into business only increases employment opportunities. Through business books, this becomes an attainable goal as they offset with their best foot forward.

The Modified Design Sprint: Simplifying a Tried and True Brainstorming Method

Written by Charis Horner on November 19, 2020. Posted in Articles.

Facilitating team brainstorming is a key skill for BAs in product development. How can we generate innovative, divergent, and executable ideas that meet customer needs?

Jake Knapp, John Zeratsky, and Braden Kowitz dove deeply into this problem and gave a beautiful gift to the BA community: The Design Sprint. (You can read all about it here.) The Design Sprint is a four- or five-day brainstorming session, with structured activities and outcomes taking a team from a big problem to a tested solution.

But what if you don’t have five days? What if you need to make a major decision and you need to do so… now? My team faced this very question and created a new version of Knapp and Co.’s game-changing process: The Modified Design Sprint.

What is the Modified Design Sprint?

The Modified Design Sprint (MDS) applies tools from the original Design Sprint to team brainstorming and decision making on a smaller scale. It uses timeboxing, collaborative ideation, heat map voting, and Decider overrule to mine information from team member’s brains and create a shared understanding. While the original Design Sprint ends with a tested prototype, the MDS gives the team prioritized, Decider-approved, team-backed ideas for further development – and it can be done in as little as an hour!

When should I use a Modified Design Sprint?

You may want to consider using an MDS when:

An effort has a lot of unknowns
You need answers to questions or solutions to problems from a diverse set of people
The team has a lot of competing ideas and you need to pick a lane
There is a lot of work that could be done, but you need to quickly prioritize the most important things

How do I carry out a Modified Design Sprint?

Fear not: The MDS requires only slightly more legwork than a typical meeting – and yields more quantifiable results.

Assemble a team

First, pick a Facilitator. This should be someone good at getting to the root cause, directing conversation, and asking open-ended questions. (Hint: It’s probably you, the BA or PM.) The Facilitator ensures the team accomplishes its goal.

An MDS is not a democracy – it’s a benevolent dictatorship, so you need a Decider. This person can ratify or veto decisions. It might be the CEO, Product Owner, or Team Lead. The MDS empowers the Decider to make fully informed decisions on key issues, emboldened by the team’s expertise.

Round out the team with anyone who has an important perspective for your effort, like other BAs, marketing professionals, developers, researchers, and designers.

Define the Goal and Questions

A successful MDS begins with a clear purpose. Are you trying to prioritize system functionality? Determine the MVP for your product? Decide on a solution for a proposal? The Facilitator and Decider should draft this goal before the session.

Once the goal is defined, you need a list of Sprint questions that represent decisions to make, customer needs to meet, problems to solve, or any other area where you want diverse team input.

Set the Agenda

Once questions are decided, the Facilitator should create a timeboxed agenda. This suggested agenda for a 60-minute session leaves 5 minutes to add wherever the team needs more.

Set the stage (10 min)
Draft Ideas (15 min)
Review Ideas (10 min)
Vote (10 min)
Decide (05 min)

Do the Prep Work

The Facilitator needs to get the room set up before the MDS. There are plenty of virtual tools for this like Miro, Mural, and FunRetro. In an online tool, set up each of your questions as a column, with sticky notes in the rows below. If you’re in person, you’ll need sticky notes, pens, expo markers or voting dots, and a whiteboard. Write the agenda, goal, and questions on the board. Here’s an example of an MDS board in Miro:

Set the Stage

Begin the MDS by reviewing the agenda, sprint goal, and explaining the Facilitator and Decider roles. Then review the question list and ask if anything is missing. If there are blind spots your team was hoping to solve, now’s the time to identify them.

Draft Ideas

Silently, everyone takes their sticky notes and answers the questions on the board. The Facilitator should give time reminders so that team members stay on track.

Review Ideas

This part is tricky; the goal of reviewing ideas is not to determine their value, but to ensure they are understood by the team. Read each sticky note out loud; if anyone needs clarity, they should speak up. Once clarity is achieved, move on to the next sticky note. For the sake of time, the Facilitator should (nicely) jump in if the conversation begins to derail. The next step will allow everybody’s voice to be equally heard.

Vote

This is where the magic happens. It’s time for the team to decide which ideas should rise to the top. There are two approaches to voting:

Heat Map: Each person has an unlimited number of total votes but can vote on each idea up to 3 times. This turns the board into a “heat map”, as the best ideas will have the most dots on them.

Tough decision: Set a voting cap, such as 3 votes per column, or 15 votes for the whole board. Each person can only vote on each sticky note once.

Decide

Using the team’s votes as a guide, the Decider looks at each column and picks the ideas which MUST be included. Most Deciders pick the highest voted items, but they can choose other items they believe are necessary. Selected ideas become the “winners” for further development. Unselected ideas can be typed up, tabled, and revisited at another time. Now you’ve got clear direction on key ideas for success.

The MDS can simplify brainstorming to quickly give the team a path forward in difficult ideation areas. Ready to try it?

The Focused Analyst

Written by Anna Rajander on November 11, 2020. Posted in Articles.

Have you ever:

Started what you thought was a simple analysis task, only to find yourself unravelling a web of mystery?
Revised work that was completed early because things changed in the interim?
Suffered from Analysis Paralysis – continually re-analysed a situation instead of moving forward?

If you answered yes to the above, you’re probably a business analyst. So what steps can you take to promote the delivery of analysis that is relevant, has a clear purpose, and is available at the point-of-need? Perhaps there are some lessons to be learnt from agile delivery.

A distinction is often made between agile and “other” business analysis techniques. However, many of the techniques that are used to organise and prioritise work in agile projects can be employed more generally. This article summarises agile principles and techniques that can be used to plan work, manage stakeholder expectations, and focus on the delivery of real value – regardless of the delivery environment… agile, waterfall, other or undefined.

1. Definition of Done

The Definition of Done is a list of criteria which must be met before a work item (usually a user story) is considered “done.” In agile delivery, the criteria are agreed by the agile team prior to commencing work. Once a work item meets the criteria, it is considered done – and “done” means done!

The idea of “done” can be expanded to work performed outside of agile projects. Agreeing a Definition of Done with relevant stakeholders is a good way to set and manage expectations and identify priorities, prior to commencing work. This can promote more focussed analysis by providing a clear end-point, reducing the risk of both over-analysis and scope creep.

2. Relative Estimation

In agile delivery, effort is a relative measure. Effort is measured by comparing tasks and assigning points. Each task is assigned a single point value (usually a number from the Fibonacci sequence) individually by each agile team member to denote how much effort they believe the task requires. Tasks that are considered more onerous compared to others are assigned a higher number of points, while tasks that are considered comparable are assigned the same number of points. Where individual point values differ, the team discuss the reasons why to reach a consensus value. As tasks are completed over the course of an initiative, the actual effort-to-point ratio becomes apparent leading to more accurate estimates.

Relative estimation is useful as it is generally easier for individuals to predict whether a task will take more, less, or the same effort compared to another, as opposed to accurately measuring the time and resources required to complete a single task without comparison. Receiving estimates from multiple stakeholders/individuals is likely to result in more accurate estimates as additional variables may be considered. While it may take time to estimate enough tasks to accurately understand how points translate into actual effort, the result should ultimately be better, more reliable estimates for a range of work activities.

3. Just Enough, Just In-Time

As a rule, analysis and design activities in agile are performed on a just enough, just in time basis – just enough to not waste time conducting analysis and/or completing documentation that doesn’t add value, and just in-time to ensure analysis is current and available at the point-of-need.

Analysis is rarely done for its own sake – it is an input for further analysis, design and/or decision-making activities. Ideally, analysis work should be completed as-and-when it is required to ensure it is relevant. Focusing on why and when analysis is required provides a foundation for delivering just enough value-adding analysis, just in time.

4. Regular Reflection

In agile delivery, a retrospective is held at the end of every iteration. Agile team members reflect on the previous iteration as a way of learning lessons and implementing changes to improve the delivery process. Open and honest feedback is encouraged, and elicitation techniques such as Stop-Start-Keep, Affinity Mapping and Brainstorming are used to promote full participation. Because reflection happens regularly, the changes required to address concerns are usually small and/or incremental, making them easier for the team to implement and monitor.

While most project methodologies promote the logging and reviewing of lessons at fixed points in time, this often happens too late to be applied to current initiatives. The regular reflection and change promoted in agile has the benefit of allowing learnings to be applied early when they may be of most benefit to the initiative. Including regular retrospectives in normal work practices can be a good way of promoting and implementing continuous improvement.

5. Focus on Progress – Not Perfection

Agile focuses on making progress – not obtaining perfection. Agile delivery sets up a system that can respond to new information through iterative feedback and refinement. Work items are constantly reviewed and revised as new information comes to light. As work items are completed, they are made available to stakeholders who are encouraged to provide feedback. It is generally accepted that initial versions will not be good enough, but that open and regular reviews will provide the information required to make them acceptable.

There are some simple steps for promoting the principle of progress over perfection in everyday business analysis. Set expectations early – never promise perfection. Engage stakeholders regularly – multiple short, sharp engagements can be more productive compared to longer one-off meetings. Focus on analysing what is important. Produce deliverables in a format that supports regular updating. Where possible, create “living documents” that are updated as-and-when information becomes available. Don’t be afraid to present work that may be incomplete or incorrect – showing the wrong answer can be an effective route to right answer.

Conclusion

Many of the principles and techniques associated with agile delivery can be employed in business analysis more generally. Pigeonholing techniques into “agile” and “non-agile” may mean suitable analysis techniques are overlooked. The principles and techniques that help agile teams organise and focus on delivering can assist in the delivery of timely, value-added analysis – regardless of the delivery approach.

Resources:

The Agile Samurai: How Agile Masters Delivery Great Software, Rasmusson, Jonathon, 2010.

Agile Alliance – Definition of Done, https://www.agilealliance.org/glossary/definition-of-done, accessed October 2020.

Defining the Minimum Viable Product

Written by Nick Webb on September 10, 2020. Posted in Articles.

When Eric Ries helped popularise the concept of the Minimum Viable Product (MVP) in his book ‘The Lean Startup’,

he defined it as ‘that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort’ . This supports products with a clear external customer and an anticipated revenue stream; allowing the team to focus on specific user sought enhancements and features while minimising the risk of wasted time and effort developing features that are not wanted. On the other hand, what if the product is being developed for internal company use; where the functionality required is fully scoped and defined? Is developing an MVP still a worthwhile activity?

In this case there are a number of benefits that can be realised by defining a Minimum Viable Product; for example, and most importantly, it enables the Product Owner to:

better optimise the Product Backlog and
descope user stories with more precision when required.

So why is defining the MVP rarely done for internal projects? There are a number of reasons for this and it can vary from project to project. I have been involved in a number of projects where the MVP has not been used. There have been a variety of reasons why this is the case:

The project is not truly agile; the Product Owner working on behalf of the client has defined user story as a ‘Must’.
Difficulty getting client buy-in; while they may support user story/requirements prioritisation, they refuse to relinquish features which are essentially enhancements to an MVP.
The product backlog is never truly completed; if the MVP is constantly evolving it is felt that it is not worth the effort developing in the first place.

However, this does not have to be the case; defining the MVP for a product should not be a burdensome task. To help us develop the MVP for internal products, or any product whose required functionality is fully known, we must first understand the purpose of the MVP and define it.
The purpose of the MVP is to deliver a working product, fulfilling the goal of the project. It does not preclude the delivery of features that add to, or enhance the MVP but allows the team to focus on the core functionality when user stories need to be descoped or new user stories are added to the backlog following testing and sprint reviews. It is important to remember that delivering an MVP allows for user feedback that that can greatly enhance the final delivered product. The MVP is not the delivery of a product with minimal functionality.

Marek Hasa identified the key elements of an MVP as follows:

Functionality – a bundle of features which are all intertwined and can be used to reach a goal within the product and receive specific value
Design – needs to meet the commercial quality standards so that the feedback of your target users is not biased by amateurish execution
Reliability – needs to be thoroughly tested and fully functional
Usability – users are able to complete target actions and gain specific benefits from using the product

The issue is identifying what the core functionality is.

So, what is the best way to identify the core functionality and define the MVP? Traditionally, this has been done through prioritisation of user stories in the product backlog or using a user journey map. Neither approach, because of their discrete nature, allows the analyst/product owner to fully understand how the user stories deliver the project goal. These approaches can also miss system features from the MVP.

To identify the core functionality of a product it is necessary to understand the relationship between the features being delivered. This relationship is frequently more than just a user journey map and needs to capture the actions required to deliver the project goal, the data requirements and non-functional requirements. The latter two support the implementation of the design and reliability needs of the MVP. Modelling this relationship allows the Business Analyst to ascertain the core functionality, the key end to end flows (though ideally this is only a single flow) that deliver the project goal. By mapping user stories to this flow a Business Analyst is able to easily identify the functionality/user stories that are not directly relevant to these flows. They can also identify functionality that can be simplified or delivered via a workaround and enhanced in a later iteration. Examples of functionality that may not be considered part of the MVP include:

Automatic upload of data via an FTP site – an interim solution may be users uploading data from an email attachment
Calculations that handle exceptions to the norm – an interim solution may support the calculations being done outside the product and the results entered manually

Once the MVP has been identified user stories can be prioritised accordingly. The description of this relationship should not be detailed; it is a high-level understanding enables analysis of what is required to deliver the project goal. The detail will be expanded upon as part of the user story refinement ahead of inclusion in a sprint. This approach enables the user stories to be easily added and removed from the definition of the MVP and the impact of those changes to be assessed.

We have looked at the role of the MVP in an agile project and how it can be utilised in projects delivering software for internal use. We have also shown how an MVP can be identified in such an environment.

Should an MVP be the cornerstone of any agile project? To better deliver a product using agile it needs to be. The benefits of identifying an MVP are:

better user story prioritisation;
user story descoping without losing core functionality and;
allows user feedback on the product so specific user sought enhancements and features can be delivered

Change Management in Project Delivery

Written by Dip Bhattacharjee on July 1, 2020. Posted in Articles. 1 Comment on Change Management in Project Delivery

A key deliverable of Business analysis in transformation projects is a successful roll-out of the Change.

Rolling out Change is a far outcry, and easier said than done. In Large organisations, rolling out the Change in an acceptable way and the associated communication about the delivery of the Change is as vital if not more important when stacked up against other deliverables in a Project. In the past, it has been noticed that when organisations could not deliver the transformation as successfully as they wished for, one of the primary reasons was that effective change management and change delivery was not among the top priorities.

It has resulted in end consumers of Change, disillusioned with the upcoming Change. Many a time, this has lead to resistance towards Change adoption, and in a few rare situations’ organisations had to revert the changes. When a change roll-out is shelved, it takes more than expected resolve and grit to take them out and re-deploy. Time has moved since it was suspended, and so does the priorities and resources.

I’ve listed below a few of the best practices that Business Analysts/Change Analysts can follow to get a more successful outcome when it comes to change roll-out and associated communications.

Impact Analysis: Firstly, conduct an Impact analysis to review what is changing, the scale of the Change, and assess the impact the Change will have on the Organisation and Consumers of the Change. The outcome of this impact analysis can be documented along with the business requirements or can be managed separately based on the project delivery approach.

As part of Impact analysis, the first step would be to conduct a high-level review to identify the impacted touchpoints. Once touchpoints are established, the next step is to identify the impact. In simpler terms, determine what is changing in the system, process, collateral, organisational structure, or people? Or any other implications such as increased or decreased workload.

Sentiment Survey: An excellent methodology to start this assessment process is to identify how people perceive the up-coming Change, a survey would provide a starting point. An important aspect to note that the study should not exceed more than 3 Questions (Ideally 1) and an optional comment section. Analyse the outcome and categorise that into five buckets viz Exciting, Happy, Comfortable, Worried, Sad.

When a certain number of feedbacks is in the last two categories, that is “Worried” or “Sad” that would provide fair food for thought for the project team. This feedback will clearly articulate the upcoming challenges and would set the tone for the Project on how to overcome this challenge. This methodology is more preventive rather than a detective. Once this survey is complete, that would set the premise for the next steps.

Identify Impacted Population: The next step is to identify the impacted consumers of the Change. This exercise must be completed at initial stages, ideally as a precursor in the project initiation phase, and will set the baseline for future scope of work. You can, however, continue to refine this outcome during the life cycle of the project delivery.

As-Is Analysis: Once the baseline is defined, the next step is to hit the As-is and to-be state definition. An As-is assessment is more important to set the tone to understand the change context and content of what activities are performed today and establish the magnitude of Change when compared against the to-be state. Unless clearly articulated, one cannot be sure to ascertain what is going to change for consumer/stakeholder when we move from current state A to future state B.

Stakeholder Engagement: This is the next logical step in the set of activities. Engage with stakeholders/delegates who are the end consumers of the Change to understand how best the Change can be delivered seamlessly with no or little disruption. Be diligent in ensuring that those conversations align with the overall organisational strategy. Project stakeholders and delegates are vital to endorse end-user feedback. Getting buy-in from the right set of stakeholders is a necessity to deliver successful project outcomes

Change Strategy: The objective of this step is to outlay the change delivery strategy. The strategy should call out for 1. Impacted Areas, 2. Stakeholders 3. What is changing? 4. How the roll-out would be perceived, 5. Mode of change roll-out, 6. What uplifts are required – who needs to be told and 7. What needs to be said. 8. Change content, and 9—the Change delivery vehicle.

A well-articulated Change strategy helps establish the next set of deliverables and work items.

Change Content: There are two primary artefacts in this space. (a) Communications of the Change and (b) Content of the Change. Communication is about how you say to the consumers about Change. It can be in one or many forms. Change Analysts must identify the best methodology that suits their project delivery timelines and budget.

Few of the communication mediums are

Emails
SMS
Notifications,
Flyers
Bulletins on Internal / External websites
Video messages from Leadership teams on upcoming Change

Similarly, with the content, there is a wide array of how the information is shared. Again a few stock standard mediums are

Help files
Animated Videos
PowerPoint packs
Reference Guides
FAQs
Dictionaries/Procedures

8. Training: There may be situations where it may become essential to train the users on the upcoming transformation/Change. There are generally a few ways to deliver that.

Train the trainer: When the complexity of the Change is high, or the volume of people impacted is high, a reasonable approach to train people across locations and geographies is to upskill a select group of people and cascade that downwards till everyone has been trained.
Train the end-user: Use this methodology when there are limited end-users, but it is a must to provide them with some form of training which they can attend, to better understand and participate in the upcoming Change.
Learning Modules: When the methodologies, as mentioned above, are deemed as not fit to purpose, one may consider publishing a training course or a Learning module. A Learning module provides flexibility and creativity that is required to upskill the people. It can be set as one with/without a test and can make it a compulsory or optional training based on the scope and scale of Change.

To summarise, change roll-outs are vital to successful project deliveries. Projects that invest in change management are more focused on ensuring a hearty handshake between Project and its target audience. Those projects generally are poised to more successful outcomes compared to ones where change management is not a consideration.