This is the last post in the Getting Requirements Right series. Here I am going to discuss requirements, their types and examples.
This is part 4 of the Getting Requirements Right post series, and in this post we’re going to explore Use Cases and how to better use them.
In the previous post, you learned about Agile approach, Epics and Themes. Today, in part 3, we are going to dive into User Stories, another useful Agile technique.
This is part 2 of a 5 part series of posts where I talk about getting requirements right and delivering them faster. In this post, I’m going to discuss process design.
In this series of five posts, I’d like to talk about getting requirements right and delivering them faster. My goal is to provide you with new techniques and approaches for producing high quality requirements on your projects.
Cybersecurity has become a familiar theme in the news. It impacts businesses, ranging from start-ups to global companies, all around the world.
A year ago, on April 15, 2015, the International Institute of Business Analysis (IIBA) officially issued the long awaited Business Analysis Book of Knowledge version 3 (BABOK V3). Here is my overview of the changes from the previous version.
My new book, “A Navigator to Business Analysis”, is now available.
I’ve recently published a new book, “A Navigator to Business Analysis”. A thing that many people might find surprising is that the second half of the book is dedicated to things which on the surface aren’t part of business analysis. Here is the list of modules in Part 2:
“Time flies. It’s up to you to be the navigator.” ~ Robert Orben
Process mapping is one of the basic business analysis tools. The technique has acquired more importance in recent times as complexity of processes continues to grow. The technique enables you to capture and visualise knowledge that resides with the people who perform daily business tasks. There are some challenges in getting the mapping right.
The Information Technology division (IT) is an integral part of any business today. Yet, it often gets the blame for high Total Cost of Ownership (TCO), redundant and legacy applications, and high IT headcount.
This is a guest post by Ben Brearley. He gives some great tips on communication techniques which improve stakeholder engagement based on his practical experience. We previously discussed this subject in this post.
We live in the era of constant change, as we hear daily in technology news and business meetings. Businesses are trying to keep up with the pace of changes by improving and transforming themselves. More and more initiatives and projects have to be completed “yesterday” meaning that they have very tight deadlines and high urgency.
While working on multiple projects over the last year, I noticed that they had similarities (evolutionary improvements were required) and as a result I applied similar sets of requirements to the solutions. In other words, patterns emerged.
There are many barriers impeding effective communication between the BA and stakeholders. Information overload, organisational “silos”, outsourcing and geographical separation across time zones all form a part of the obstacle course BAs navigate in their job. In some companies, ineffective management, internal politics and bureaucracy lead to poor staff engagement. People in such places aren’t interested in contributing.
You have probably seen the scary statistics of failed projects. They often reveal that the major cause of project failures is poorly defined requirements.
While preparing for ITIL certification a while ago, I participated in practical games showing the importance of ITIL principles. The Service Desk team was the most stressed in those games, as it was trying to handle multiple incidents of different nature.
I’ve recently been involved in a discussion on how to better prioritise requirements. It’s an important topic because the requirements prioritisation process can get rather lengthy,and it’s good to speed it up.
There is a lot written about use cases and their application in business analysis. A good understanding of the business context is required to develop use cases which will deliver good value to a business customer.
In the previous post we’ve established that the success of business analysis hinges on communication, and postulated that visual communication is the easiest way to improve productivity and the effectiveness of communication.
It struck me the other day that business analysis as the name of the profession doesn’t really reflect what’s involved in it.
In this followup to the Beachcamp series, we show how different knowledge areas from the BABOK come into play in a real life project.
This is the final instalment in the Beachcamp series. We talk about the requirements structure which helps produce complete requirements.
This instalment of the Beachcamp series is about the requirements lifecycle, and includes a visual map of the relevant section of the BABOK.
This instalment of the Beachcamp series touches on the subject of solution assessment and validation, and includes a visual map of the relevant section of the BABOK.
This is the sixth post in the Beachcamp series. In this post, we discuss requirements analysis and provide a visual map showing what’s involved in it.
This is the fifth post in the Beachcamp series. In this post we talk about requirements management and communication and provide a visual map of the relevant section of the BABOK.
This is the fourth post in the Beachcamp series, discussing requirements elicitation. It includes a visual map of the requirements elicitation section.
This is the third post in the Beachcamp series. This post is about the Enterprise Analysis section of the BABOK.
This is the second post in the Beachcamp series. This post is about the Business Analysis Planning and Monitoring section of the BABOK.
We are starting a series of posts to illustrate the structure of the BABOK, and the interconnections between the different knowledge areas within it, and the links between the elements within knowledge areas.
We have published Business Analysis Lifecycle, a whitepaper which introduces the concept of BA lifecycle in order to ensure that lessons learned are incorporated into all BA activities.
This is a short post to share an idea we’ve come up with. We’ll publish a longer article once we work things out in detail, but we thought that it would be useful to talk about the idea right now.
This post discusses what business analysts can learn from the Sarbanes Oxley Act requirements for the purposes of establishing an effective internal control system within the enterprise.
In this article we discuss the proliferation of architectures and we present our high level view of enterprise architecture to try to demystify architectural complexity.
When you hand a project over to another BA, or when you are taking over from somebody else, it’s important to make sure that the appropriate information is transferred. This post will tell you what to look for in this situation.
Before getting into requirements gathering, a BA needs to collect certain information and produce documents to ensure a smooth start to the project. This article details what needs to be done, and provides a summary checklist.
The majority of business analysts don’t have the tools which would help them work more effectively. We’ve identified some problems which we can solve by developing a requirements management tool. You could help us make it more useful to you by providing input and feedback.
The introduction of a CRM is a complex endeavour which requires careful planning. This article presents a roadmap for CRM system implementation and explains who needs to be involved, what needs to be done before the implementation, and what steps the implementation process should include.
A large portion of IT projects fail or are challenged in some way. The cost of failed IT projects can be enormous. This article examines the impact of requirement quality on the project and business as a whole.
As discussed in the previous post, prototyping is one of the cost effective ways of presenting an approximation of a working system to the stakeholders to validate the concept and work out the kinks.
The complexity of modern solutions along with the required investments have made prototyping a necessity. A “proof of concept” is normally required to justify the feasibility of undertaking costly projects.
Business analysts and project managers need to be able to present their work (e.g. findings of completed analysis or proposed changes to business processes and underlying systems). If you google “executive presentations”, you’ll get a lot of links but quite often these resources are focused on how to prepare to and behave during the presentation.
This article introduces a summary chart for business process mapping. The chart shows both a brief and a full format for process mapping.
Despite the ongoing process of business analysis maturing as a discipline, the question of getting requirements right is still debated on various business analysis related web sites. Poorly defined requirements are still quite common.
I would like to talk about the skills a business analyst needs because we at Aotea Studios believe that business analysis is a more complex job than is commonly acknowledged.
This post shows a chart of roles and responsibilities within an Agile team. It also discusses the role of the business analyst (spoiler: it’s still vital).
I was talking to an architect about a holistic model of enterprise architecture which could facilitate the collaboration of BAs and architects. The architect referred me to TOGAF 9.0 (the latest architecture framework) where I could find the model. After spending some time on reading, I realized it does not contain the model I was interested in. TOGAF 9.0 contains high-level meta-models and their extensions. It is worth reading but it does not solve the raised problem.
After publishing the business rule model poster last week, we received a suggestion from Adriana Beal to provide an example that would illustrate the components of the model. Let’s consider a real life situation, purchasing a book from an online store (with an added constraint of no more than 10 items per customer). Here are the steps a customer would go through to make a purchase:
Business rules are at the heart of all validations for a business software package. The article Seven deadly sins of business rules by Larry Goldberg supports this viewpoint. Sin number 4 in the article is: “There is no standard for a model of business rules that is technology-independent and against which testing can occur early on”.
This is the final article in the series on the structure of business analysis documents.
This article is the first in a series describing business analysis artifacts, their purpose and internal structure
I’ve talked about ways of managing your work when you’re faced with a tight deadline. This time I’d like to discuss ways of managing the deadline itself.
Our change management poster proved to be the most popular to date, with over 2000 downloads and over 150 people saying thanks or suggesting improvements on LinkedIn and forums. Thanks again to everyone for the feedback!
First of all, I’d like to say we’re really grateful for all the feedback on our previous posters. Lots of people are still saying thank you for our change management poster published over two months ago, which is amazing!
There seems to be quite a bit of hype around Master Data Management. I even saw an article recently that talked about an “AI technology” which ensures data integrity and enhances search effectiveness. Nevermind that artificial intelligence doesn’t exist anywhere, let alone in business software. Of course, vendors have a vested interest in making it sound like rocket science, but does it really have to be that complicated?
We all know about the importance of meetings and how they help to get people on the same page. But we’ve all been in meetings that dragged on for hours, meetings where the discussion was wandering all over the place, and meetings with far too many people in them.
UPDATE: There is an updated version of the change management poster here.
I’ve recently had a knowledge sharing session with new graduates, and one of the questions from the session took me some time to answer properly. The question was about enterprise architecture and how BAs should approach it in their projects, and it led me to creating this poster which shows several layers of enterprise architecture with key components within each layer:
When you are assigned a complex project that has a short timeframe (as often happens), it can be nerve wracking - I know this from experience. It’s like driving a racing car - you have to push close to the limits but any error can throw you completely off the track. I’ve found that following a few practices helps me complete such projects on time:
Having completed the PRINCE2® Foundation Course, I was inspired by the elegance of the methodology and process orchestration, and I thought, “Wouldn’t it be great to show it from the BA’s point of view?”Project managers and BAs work together closely, and I wanted to show that interaction throughout the main stages of a project. While I was at it, I decided I would also list all the documents written in the course of a project. I ended up with a poster that shows
This poster provides an overview of the BABOK business analysis framework: