Why Every Job Seeker Should Have a Personal Website, And What It Should Include
Business Analyst Community & Resources | Modern Analyst
RSS feeds for Business Analyst Community & Resources | Modern Analyst
Identifying requirements, the right way
Requirements define the needs of the project to provide best of its utility and benefits. If they aren’t clear or analysis is not done properly, it might lead to failure of the project no matter how good the concept and design is.
Just as a system is composed of various functionalities, requirements too are identified in various forms. This categorization of requirements makes analysis process much simpler and clear for all the involved stakeholders. As per BABOK, the requirements are primarily categorized as:
- Business Requirements
- Stakeholder Requirements
- Solution Requirements - Functional and Non-Functional Requirements
- Transition Requirements
With so many requirements to identify it is very easy to get confused with how to identify these requirements?
A simple approach is to visualize the complete process and start step by step
To do that, let’s look at cooking for an example:
When you plan to cook a meal, you first take in account for whom you are cooking. Is it for yourself or for your family or the kids? These define your Business Requirements. Once you decide this, you figured that you will sip wine along with the food and the kids won’t eat spicy food (stakeholder’s requirements). Next, you get all your ingredients for the meal (functional requirements) and you might also take in consideration the time you require to prepare the meal and preparation required for serving the food (Non-functional requirements). Finally, you prepare a delicious penne arrabbiata pasta topped with oregano and basil leaves (technical requirements).
Now, let’s understand each of these requirements with a technical example, Implement Log-in functionality.
Business Requirements: These are high-level business objectives or goals or needs of an organization. The business requirements document (BRD) usually includes what features would be there in the product, what market the business will expand or enter, risk assessment, success measures from the business point of view, etc.
Example: There shall be a Login screen through which Users will log into the system.
Tip to identify:
Words or phrases that describes what, such as “we need to be able to”, “we need to solve this” and “we need a way to”.
Stakeholder (User) Requirements: These are what every stakeholder needs/expects from the solution and how they will interact with the solution. Often the stakeholders can explain the entire system in detail from their perspective only. Each stakeholder sees the problem from unique perspective. Therefore, you must understand all the needs to understand the complete system. All these requirements must be analyzed in such a manner that it doesn’t conflict with each other.
As a customer, the user shall be redirected to Dashboard on successful login. (Stakeholder - Customer).
As an admin, the user shall be redirected to the Administrator’s landing page on successful login. (Stakeholder - Administrator).
Tip to identify:
Similar to business requirements, but from user's perspective. Words or phrases that describes what, such as “we need to be able to”, “we need to solve this” and “we need a way to”.
Solution Requirements: These specify the detailed conditions and the capabilities that the solution must have to meet the business and stakeholder requirements. Software Requirements Specification (SRS) is created to capture both functional and non-functional requirements. These are categorized into two:
a. Functional Requirements: These define specific behaviors, responses, information, rules for the solution primarily addressing the following:
- The features the system will support (Functional capabilities)
- Data validation rules and how they will be managed (Business Rules)
- Interaction between different stakeholders (users) within the system (Use cases)
These include a complete description of ‘how’ the system will be built.
- Registered users shall be able to login with valid username and password
- On successful login, user shall be redirected to a landing page in the system
- On failure, for not registered username prompt "Username not registered" message and for invalid credentials prompt "Invalid credentials"
- New users shall be able to register with the system by clicking on the "Sign-Up" link
- Users shall be able to recover password by clicking on "Forgot Password" link
b. Non-functional Requirements (Quality-of-service): These define the environment in which the solution will operate. The qualities a solution must have or constraints within which it must operate smoothly. They define standards for Usability, Reliability, Security, Accessibility, Performance, Information Architecture, Portability, Extensibility, Internationalization, Integrity or anything that would help the success of the system in real-world.
- Performance: On successful login, user shall be redirected to the landing page within 10 seconds (max)
- Maintainability: Proper logs stating the operation result with timestamp shall be added on every login/signup/forgot password click
- Platform: The login functionality shall behave same on different platforms (Windows/Linux)
Tip to identify:
To easily identify between these, functional requirements can be considered as “verbs” and non-functional requirements as “adjectives” on these “verbs”.
Transition (Implementation) Requirements: These define conditions or capabilities only required to enable transition of the solution from development to real-word business use. It describes what must be done with the process, technology, education, training, enhancements before getting from the as-is into the to-be.
Example: Not valid in this example but for explanatory purpose: The login system shall behave same once "Single Sign-On" functionality is implemented
Tip to identify:
Look for temporary requirements such as “migrate from old system to new system”.
There are many other types of requirements that are used across diverse types of systems based on the scope such as:
Technical Requirements: Once the solution requirements are clear, the best way to start with the development frequently involves technology. It is a way to communicate between analyst and engineers (programmers, architects, designers) and is often written by the technical engineers. These requirements specify design and architecture for the solution components to be developed and implemented. They define how the solution will be programmed, store data and display data.
- Browser support: Current and recent versions of Firefox, Edge, Chrome, Internet Explorer, Safari, Opera
Tip to identify:
Technical jargon's are used such as “password encryption algorithm” and “database schema” etc.
User Interface Requirements: These define the user interface design for the functionalities (derived from solution requirements). The placement of user input controls, buttons, links etc. on screen to allow the working of the functionality. Generally represented with wireframes.
- Textboxes for username and password shall be placed below the respective labels for Username and Password
- Login and Cancel buttons shall be present in center of the screen
- Sign-Up link shall be present below the Login button
- Forgot password link shall be present above the Login button
Requirement analysis is all about understanding, identifying and categorizing these requirements. With categorized requirements, it becomes much simpler for the team to understand and follow the system details.
Challenges in Implementation
Challenges in Implementation:
I’m a strong believer of putting finishing touch to any initiative. Project Initiation is always tough and complex and need lots of research but if BA is unable to give the finishing touch then he is not done yet. So, I thought to put few of my views, challenges and observations during Implementation phase that I have faced. BABOK does a great job in explaining the Strategy Analysis and Solution Evaluation however real time challenges are most of time unspoken. As a Product based Business Analyst I often face few challenges which are altogether different than the last one.
Stakeholder involvement and Governance: This is one of the challenging and critical step to find out the exact governance of stakeholders. Each stakeholder interest towards the product implementation do impact the final stage of the product. Lack of interest do hamper the product implementation. So if any stakeholder has less interest so its critical to know the reasons. Sometimes its better too to know why if any stakeholder shows more than needed interest. Maintaining correct and verified Project Charter does help in this.
Over Expectation: Customers are always demanding and they should be as they are the one who are paying for all these, however as a Business Analyst you must be very smart to distinguish the expectation and over expectation of client because over expectation often makes your system more complex to use by the end-user and customer which ends with spending more bucks and gaining less.
Deadline and Release Planning: As a business analyst make sure that circumstances don’t control you and your team, and you deliver your project successfully even if you don’t meet the original deadline. The art of prioritizing the solution requirement helps you to pass through. You should keep some time in buffer so that you have availability of resources to fix the unwanted issues or the deadlock condition in approval or implementation.
The Acceptance: Most of the time I have found more involvement of people in acceptance compared to when you do the brainstorming or focus group. Sometimes customer say that they aren’t looking for this altogether. So, providing a view of your product before acceptance saves you. Do not ever try to give more than requirement (without information), customer will treat it as a bug because they haven’t requested it. Though sometimes over-explanation saves.
Training: Sometimes it happens that everything is as per the client request and you are at a better stage to close the project but you end with hearing that there is no such benefit by the new implementation. I have observed that sometimes the user is not aware of the new feature or do not know how to use the new feature at all. So, Training to right people is very important. Sometimes you should move desk by desk to see if customer the using it fully.
Getting feedback: Learning from your mistake is very important however knowing what went perfect is important too. Feedback from customers is very important to learn and grow as a business Analyst.
There are number of other challenges that do a Business Analyst phase. I would love to hear.
All professionals talk about identifying business needs, identifying requirements to create tools so that they can help businesses take better decisions. In your career as an IT professional, I am sure at some point you must have heard terms such as “Requirements”, “Business Requirements”, “Software Requirements”, “Project Requirements”, “Technical Requirements” and the list goes on.
So, what are these requirements?
“Ours is a world where people don’t know what they want and are willing to go through hell to get it.” — Don Marquis
Well, to most of the people, this appears to be a simple question. But, this is the most complex question to answer (for the professional responsible to gather requirements, primarily a Business Analyst) as it takes forever to ask and understand “What are the requirements”.
Different people have different ideas of requirements. For a product owner, requirement is as simple as the ability to use/sell the product that helps with the business and revenues. For a project manager working on that solution, requirements are to get the solution developed with best quality that meets all the expectations of the client and minimize resource allocation to bring most benefits to the company. For a team lead, requirements are to identify the technical challenges, build a maintainable architecture and get the solution developed smoothly. For a developer, requirements are to develop the assigned feature or make changes in the software as requested.
Requirements, at first glance are really needs (end objective), wants, suggestions or ideas. Derived from those needs, we set an objective and take a decision about what things should be done or not to be done to achieve that objective.
Requirements are a set of prioritized needs from all the involved stakeholders that form the base for the functionalities or features to be included as a part of the solution.
Per BABOK guide, official definition of requirement is:
1. “A condition or capability needed by a stakeholder to solve a problem or achieve an objective.” In simpler words, a decision-making process to derive requirements from needs.
2. “A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification or other formally imposed documents.”It is a step where business requirements are drafted as solutions requirements to get started with developing the solution.
3. “A documented representation of a condition or capability as in 1 or 2.” The documentation is itself a requirement as it helps all the stakeholders and consumers in understanding the requirements for the solution.
Where do these requirements come from?
All the requirements arise from a need. We need to understand those Business Needs or the Business Problem Statement. Unless there is a problem, we can’t think of providing a solution. A lot of analysis and research is carried on before requirement analysis to understand the problem. These involve feasibility study, knowing business terms and concepts, cost/benefit analysis, business strategy etc.
A Business Analyst (BA) starts with a broad and general description of what needs to be done and then starts working with key stakeholders to define the project scope (inclusions and exclusions), high-level business requirements, solution requirements, technical requirements and transition requirements primarily.
Talking about stakeholders, it’s important to know about who they are and how critical is their involvement in the project.
Who are stakeholders?
A stakeholder is a generic term for a person or group of people who are involved with the project (directly or indirectly) and have a say in decision making process of the project. They can be:
- Executive Sponsor — Mostly concerned about funding of the project and high-level information
- Product Manager — Make important decisions for the project and review & approve requirements
- Project Manager — Prepares project plan, resource allocation plan, manages the execution of the project and works very closely with the BA (Business Analyst
- Subject Matter Experts — Assists in defining project scope, works with the BA to define business rules, processes and user interface
There is a whole set of other roles such as Technical Personnel, Technical Writers, Quality Assurance Personnel, Database Administrators and others who can be important stakeholders in a project, depending upon the needs.
How stakeholders help with requirements?
Since each stakeholder plays a different role in the project, they have different requirements too. Sometimes, what emerges as the biggest challenge for a BA is to extract useful information from all these stakeholders that matches the preferences best with the client’s business. This is because each of them view the project from their own perspective!
To create best requirements for a project, identifying responsible stakeholders is important. There are many techniques available such as RACI matrix. Not all stakeholders are important for every project. It is primary task to identify the right stakeholders and their say in the decisions to keep things smooth in long run. (When all speak, it becomes real hard to reach to any conclusion).
How are requirements identified?
“The most difficult part of requirements gathering is not the act of recording what the user wants, it is the exploratory development activity of helping users figure out what they want.” — Steve McConnell
The process to identify requirements from the needs or conditions is termed as Requirements Analysis. A detailed analysis is critical to solution’s success or failure. It involves the tasks as analyzing, documenting, defining, validating, documenting and managing the changing requirements. There are different standards set in different organizations for the requirement analysis though the primary steps could be identified as:
- Identify stakeholders
- Requirements Elicitation — capture stakeholder requirements through various techniques such as interviews, questionnaire, joint group discussions, prototypes or use cases
- Identify requirement categories — categorize all the gathered requirements into functional, non-functional, business, technical or transitional requirements
- Analyze requirements — analyze the requirements whether they are clear, complete, unambiguous, consistent and testable
- Requirements documentation — requirements are documented in various forms such as Business Requirements Document (BRD) to describe business requirements, Software Requirements Specification (SRS) to describe functional and non-functional requirements, Use cases and User stories (in agile context)
These recorded requirements documents are then collaborated upon to receive feedback from all involved stakeholders. Once the requirements match the needs for the project, it is important to take sign-off to freeze the scope of work and avoid frequent scope creeps at later stages.
Why are requirements important?
Per new research,
- Success in 68% of technology projects is “improbable.” Poor requirements analysis causes many of these failures, meaning projects are doomed right from the start
- Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their project
- Over 41% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization
Requirements serve as the basis for the project plan and if there are inadequate or incorrect requirements, entire project will suffer at the end.
- They are used as inputs into the design stages of product development
- They are important input for verification process for the product developed
- They represent what functionalities are necessary for the product
Excellent requirements leave no room for interpretation, confusion or omission of critical details and is easily understandable by everyone involved in the project.
Next time when you start with your project, make sure you have all your #requirements…clear and loud!
Stay tuned for more with requirement types, characteristics and more coming up!
Experience Age - a new era
A few weeks ago, one of my colleagues surprised me with a statement he made during our team meeting that the information technology age is coming to an end. I looked at him in complete disbelief. How can the advances that have brought so much convenience to our lives be said to be coming to an end. I thought he must be mistaken, and just like a student who has just been given a topic for an assignment, my curious nature of always wanting to know kicked in and I set out on my little research – not to pass this time, but to prove him wrong. I asked myself how can we live without information technology, and how can life be better without information technology, which has brought with it globalization – a concept that shrunk the world into a small village.
However, after reading a few articles on this topic, I realized that just like there were other ages before – for instance, during the 17th century human beings lived off the land, and were mainly agrarian. During the 18th century – the Industrial revolution happened – ushering in a new era in the history of mankind – the Industrial age, and continued to evolve through to the 19th century. That too subsided in the 20th century and gave way to the new kid on the block – technology, which revolutionized communication by introducing telephone, radio and television. And we have come a long way since then.
Needless to say, the advances that have been made in the technology space have been in leaps and bounds since the invention of the telephone line, and created what has come to be known as the ‘information technology’ or ‘information economy’ age. It is the world as we currently know it, and as we currently expect to operate. However, the earth has never stopped moving….it continuously orbits the sun 365 days a year. This means that, as much as we have felt comfortable with what we have come to know - the ‘information economy’ age – this period was also never here to stay either. At some stage, just like the earth is consistently in motion – this age would have to come to pass, and make way for a new order of things.
At the centre of the information technology age is the focus of acquiring, storing and processing data to meaningful information and insights to better organisations’ economic progress. And as we in the first quarter of the 21st century, the non-stopping advances in technology are preparing us for a new era – the experience age. It is reported that by 2025, which is a mere 7 years away, the virtual reality experience will be almost close to the new reality – such that conscious efforts will have to be made to make people to be able distinguish between the real ‘reality’ and the ‘virtual reality’. This age will bring with it a complete paradigm shift – from how data is collected, stored and processed to become meaning and useful information in the form of business intelligence to how consumers will experience products and services offered by organizations.
The significance of data collection and/or data mining to gain customer insights will no longer be of primary focus. The experience age will necessitate the creation of virtual reality for the consumers to experience a product and/or a service even without buying it. For example, they will feel like they are ‘physically’ at the stadium watching a soccer or rugby match, while sitting in the comfort of their homes.
The experience age will extend the use of technology even further. It will allow for the use of technology to enable the consumers to experience a product or a service in that moment as if it were real or as if they were already consuming it, even though they were still trying it out. Some of this might sound far-fetched and just a fantasy. However, who would have thought that the demand for voice calls on mobile devices would be replaced by the demand for data services like WhatsApp – a move that has just happened over the past 5 – 10 years? And to push the envelope even further, the demand for data services for chatting and sharing of pictures or videos will soon be replaced by demand for data services for video calls – something that Facebook has realized and now introduced video calling on WhatsApp. Consumers will demand the experience of seeing each other as they are talking to each other. Yes, this is already happened in some parts of the world, but not at the ubiquitous level at the moment. This is the experience age shaping up right before our eyes.
The experience age will also be of great benefit to the services market. At the moment, consumers can only experience the quality of the service offered by a hotel by physically staying at the hotel. However, with the advances in the experience age, the consumer will be able to take advantage of the virtual reality and experience the stay at the hotel before actually staying at a particular hotel. At the moment, all that thought and decision making process of which hotel to choose is driven by data – either personal or impersonal, i.e. either through word of mouth from friends who have stayed over at that hotel, or through what the hotel publishes about itself on websites, brochures and other sources of information. And all of these touch points may prove, as some of you may agree with me, very deceiving and lead to a disappointing experience.
In the product market space, gamification will probably become one of the dominant form of introducing the experience age to the consumers. In this way, technology will be used to create games for customers to experience the product they are interested in even before buying it – as part of playing the game – as opposed to reading about what the product can do or see the TV ads about what a product does.
We cannot speak about the experience age and leave out the new buzz word, the IoT – the internet of things. This concept simply means that every device with a power switch can be hooked on to the internet – the connectivity to the internet will not only be exclusive to devices such as laptops, computers, mobile telephones. These devices include cars, televisions, fridges etc. The ability of these devices to connect to the internet will also change how we ‘experience’ the world we live in.
Cars will be able to communicate with each other, with the traffic lights, with mobile devices of the people you are having a meeting with to advise them that you are running late, to identify roads congested with traffic due to accidents or traffic lights that are out, and to decide alternative routes. Fridges will be able to contact your local supplier to order milk or whatever it is that you will be running short of. We currently see the advances made by smart TV’s which are already able to connect to the internet. Thus the IoT will be another form through which the ‘experience age’ is rendered to us by technology.Therefore, the paradigm shift I referred to earlier on means that organizations will have to change their strategies, as the focus will no longer be on relying on big data to run analytics, but rather on using technology to provide real time experience to acquire and retain customers. The experience age calls for a different mindset, bearing in mind that consumers are also changing. We are talking millennials now, and no longer the X’ers and the Y’ers – and they have a different view of the world – which is proving to be a challenge to both their employers and companies offering services or products to them. And I believe that this is food for thought for us in the information technology space. In order to adapt, companies have to gear themselves and their mindsets towards IoT, robotics and experience age to remain relevant and up to date with the new era.
10 TIPS FOR A BA TO WORK EFFECTIVELY WITH A PROJECT MANAGER
The Business Analyst and Project Manager are team players on a project. As is common the Business Analyst and Project Manager sometimes have conflicting approaches during a project.
Having frequently taken up dual roles of a project manager and Business analyst during the course of my career, I have gained some insight on the dos and don’ts for a business analyst to work effectively with a Project Manager
The following are the 10 recommended Tips:
TIP 1 – Collaborative Stakeholder Analysis
Key to your success as a Business Analyst on any project is identifying your key stakeholders and having a good understanding of their interests and levels of influence. From my experience this is a task best done in collaboration with your Project Manager to ensure you speak the same language when it comes to managing your stakeholders. Imagine a situation where you haven’t captured the requirements a highly influential stakeholder already identified by your Project Manager. This could in turn result in unwanted reworks on the project, increased costs and project delays.
TIP 2 – Synchronization of your Business Analysis Plan with the Project Schedule
It is good to ensure that the activity dates of your Business Analysis Plan are incorporated or synchronized with the Project Manager’s Project Schedule. Nothing is worse than discovering that the period of time the project manager has allocated for your Business Analysis Activities is insufficient.
TIP 3 – Usually not all requirements can be captured up front.
Many Business Analysts discover that as much as the intention may be to capture all requirements up front before the execution phase, there are actually few cases where this is possible. During execution it is common that stakeholders bring up forgotten requirements. The good news is that usually the Project Manager will define the Acceptance criteria with the client. The acceptance criteria is an agreement of what the product or service should constitute for it to be accepted by the client. The Acceptance criteria are usually part of the signed off project charter. Other Project Managers may use the agile approach where prioritized requirements are implemented in phases. In summary A BA must accept the fact that in most cases not all requirements will be captured up front.
TIP 4 – Non Functional Requirements vs. Project Scope
As Business Analysts we also capture non-functional requirements i.e. the expected efficiency level of a system. It is good to liaise with your Project Manager on what is out of scope for the Project. It is common that non-functional requirements requested by stakeholders are sometimes not feasible due to budget and time constraints. In summary you need to be on the same page with your project manager on what is out of scope. This is to avoid complicating the management of your stakeholder expectations
TIP 5 – Help to minimize Scope Creep
As business analysts we know that stakeholders may request additional requirements during the course of the project. As Business analysts a new requirement is accepted or rejected depending on whether it can be directly linked to the Business Need. However Business Analysts need to remember that project manager aims to minimize new additions to the project scope (Scope Creep) that will require the adjustment of the Project budget and Schedule. In most cases stakeholders are not willing to incur the increased cost or time required for inclusion of new requirements.
TIP 6 – All changes to requirements undergo impact analysis
Whilst carrying out the Requirements Management & Communications process the business analyst must ensure that changes to requirements go through the Impact Analysis process managed by the Project Manager. This is to ensure that the Impact that a change in requirement will have on the Project Schedule, Project Cost or product quality is assessed before the requirement change is formally approved.
TIP 7 – Collaborative Prioritization of Requirements
Prioritization of requirements is a standard task that we carry out as Business Analysts under Requirements Analysis. However it is common to reach a road block where stakeholders wish to classify all their requirements as high priority. This is usually due to the fear that non high priority requirements will be excluded in the project scope. With this in minded it is recommend that prioritization of requirements is done with the involvement of the project manager to assist in management of your stakeholders.
TIP 8 – Synchronize the list of prioritized requirements with the vendor selection criteria
Selection of vendors is procurement management task that critically requires the input of the Business Analyst. Selection of vendors is usually based on each vendor being evaluated against the vendor selection criteria defined by the project manager. It is crucial that Business Analyst ensures that the vendor selection criteria is synchronized with the list prioritized requirements.
TIP 9 – Transition Requirements can sometimes be implemented as post GO LIVE tasks
Business analysts also capture transition requirements i.e. the required training of users. For a Business Analyst a project is complete when all the categories of requirements i.e. transition requirements have been implemented. However what is sometimes experienced is the Project Manager wishes to separate the implementation of transition requirements from the Project Scope and treat transition requirements as post GO Live tasks. This is usually the case when Project has a non-negotiable constraint on the GO Live Date.
TIP 10 –Factor in Project Manager’s constraints and assumptions when the defining the solution scope.
The Business Analysts defines the solution scope under the process of enterprise analysis. It is critical that the Business Analysts gains the input of the project manager on constraints and assumptions before defining the solution scope.
To work effectively with Project Manager a Business Analyst has to be able to understand aspects of stakeholder analysis , Project Schedule , Project Scope , Managing scope change , vendor selection criteria and project constraints from the eyes of a project manager.
9 Traits of an Incredible Awesome Leader
There are hundreds of traits that make up a good manager, but here are the top 9 skills we recommend for a business analysis leader - or any leader in general.
1. See Design as a Differentiator
Anyone can design but not everyone designs well. Who cares? Frustrated users care. Seeing design as important sets you apart from all other business analysts that don’t’ give it a second thought. Build interfaces that are practical and good looking. Don’t see design as something someone else does – it something you as a business analyst can do.
2. Build the Vision – Be Adaptable to the Approach
Build consensus and a strong vision for the outcome. Share the vision of the outcome for the project far and wide to gain a common understanding within your organization on the vision. Share frequently and share often. Implementing the vision can take a thousand paths. Be adaptable. The way to realize your vision isn’t going to be on a clear cut path – there will be many forks in the road. Understand that planning is important in elicitation of requirements and design, but it’s volatile and subject to frequent changes. Create a planning approach the ensure your path forward is well understood, but balanced against overly complex and detailed planning.
3. Understand Your Customers & Users
At the heart of the vision lays the core user. These are the users that interact with your applications, systems, and processes every day. Without
4. Don’t Plan More Than 18 Months Out
Long term planning past 18 months is impossible. Markets and organizations change too rapidly to have road maps or long term planning past 18 months. The second you produce that 5-year plan it’s obsolete. Keep fluid in your planning to reach your vision. You may need to re-group or re-think your approach several times over. It’s better to be aware that you need to change your approach and planning frequently than to forge ahead thinking it will be set in concrete.
5. Plan, Perform, Evaluate, Adjust
We talked about planning above. Here’s a cycle that works:
A. Plan It Out – choose your path to reach your vision. Keep a Requirements Work Plan (RWP). Build the consensus and understanding on the tasks you are performing for the project.
B. Perform the Plan – don’t let the RWP sit idle. Work to carry out the tasks outlined and meet the dates you assigned yourself. This builds trust.
C. Evaluate continuously – be aware your best-laid task list could change in an instant. Be aware of other activities or projects that are pulling you away from meeting your plan. Check your progress against the plan and know when things are going off plan.
D. Re-Plan Proactively – get yourself back on track and re-plan frequently. Keep your team aware of the re-planning process and why re-planning was needed. Frequently re-planning is better than falling too far away from the plan and missing expected dates. There are no hard and fast dates no matter what the project manager tells you.
6. Don’t Rely on One Method of Communication
Email is tried and true but not the only way to communicate out your status, projects success or potential changes to users. Everyone is overloaded with email. Find a new channel of communication to keep your project’s vision and potential organizational impacts visible. Personal notes, open houses where anyone can swing by during a 2-hour period to ask questions, and even hallway meetings are a great way to communicate.
7. Focus on Opportunities – Destroy Problems
Only focusing on problems takes your eye away from opportunities that will bring better results. Choose the bright side and be optimistic in your attitude. New opportunities will present themselves. Be prepared to take advantage of them. Find problems and get to the root cause – then destroy them. Don’t focus on trimming a problem’s branches or cutting it down instead, kill at the roots. Don’t let the problem linger around or give it the ability to grow back.
8. Carefully Build the Team – Build Strong Relationships
If you get the chance to choose team members, then choose carefully. Listen to your gut feeling and don’t bring on board resources that you don’t or can’t trust – even if you can’t explain why. It’s hard to put into words sometimes why you don’t trust. Choosing the right members for the team will make or break the vision. Maintaining a team is equally important. Spend time every week celebrating or gathering the team informally outside of the daily stand-ups or weekly status meetings. Try to hold that meeting somewhere different and fun. Even moving to a different conference room will oddly change the team’s perspective – especially if they are trapped in the same war room every day. Always be grateful and reach out to say “Thank You”. Remember those different communication channels? Don’t always email – try a hand written thank you card or just ask them out for a coffee to say thanks for their help. Building the strong relationships get you through the tough times in a project.
9. Know Your Strengths – Outsource Your Weaknesses
You are not everything to everyone. Figure out your strengths and what you are good at. Personality tests give you a hint but ask around. Listen to what your colleagues, friends, and family believe your strengths are. Play to your strengths – you're strong at certain things for a reason. Know your weaknesses – then outsource them or engage someone to help you overcome them. Ask for help. For extra credit build the project team knowing the strengths and weaknesses of everyone on the team to balance them out.
So here’s the truth. As leaders and contributors in the Business Analysis field, these are the skills we need every day. They are also the skills that founders of companies hold.
Check out more great blogs at Bob the BA today!
Are You Being a Design Illusionist?
As business analysts, we are often in the fray of designing. Whether it’s a user interface, report or data fed from one system to another; business analysts create interfaces with human beings and systems. Our design choices impact users and other systems in a very real way. This power can go unnoticed even in our own minds.
Have business analysts become illusionists and pickpockets? Both these skill sets require some of the same sleights of hand. The illusionist uses the blind spots and limits of human vision to fool us. If you haven’t had an opportunity to watch the show called “Brain Games” – give it a whirl. It does an excellent job of explaining how an illusionist can fool our sight and point of view. For the pickpocket, it’s the distraction of a conversation, a tap, or a bump to set your mind off in the opposite direction of where you should be focusing while a sleight of hand takes your wallet.
Are we as business analysts playing a role of illusionist and pickpocket when designing our interfaces? Let’s look at interfaces (such as screens and reports) in a broader sense. An interface in my mind is the presentation or “stage” an illusionist would use.
We all believe we have choices and freedom. Everyone in the western world most firmly believes they have great freedom of choice in being able to do whatever is desirable, affordable and of course legal. You can go just anywhere and do just about anything. But when confronted with a system, website or application with a menu of choices, we fail to see how we are hijacked.
We rarely ask the questions:
(1) What is NOT in the interface? Or why are these my only choices?
(2) What is the purpose or goal of this interface? What is it used for?
(3) Why are these options higher or lower on the interface? More visible or less visible as other choices?
(4) Are these choice empowering me or just distracting me from doing what I need to accomplish?
If you have every used a search engine like Google or an application like Yelp, you get a sense choices are made for you and only certain things are being presented for your attention. I have been told the nearest restaurant or gas station is several miles away – all the while standing right in front of one! I usually chalk it up to “well they must not have gotten into the database yet” but now I’m leaning more to thinking I’m being fooled by the choices I’m presented.
Back in the ancient days at the dawn of computerized civilization – something like 40 years ago for you youngsters – computers
In those ancient days of computer myths and data Gods, there was but the humble green screen. To get to all the crap stored in that giant mainframe required you to issue the magic commands. By locating the secret words in the sacred text called “Command Line Reference,” you could instruct the mainframe beast to perform feats of great wonder. In other words, there was a giant three-ring binder with all these commands listed in alphabetical order that you were required to memorize and type correctly. The mainframe didn’t tolerate spelling mistakes, and there was no such thing as auto correct. No Google-like “Is this what you mean?” ever appeared on the screen. Even the help key which was supposed to provide assistance rarely did. This was the world of complete freedom from “the menu”. All the commands were in the book and available and granted they didn’t cover everything you wanted to do, but they did cover a lot of stuff you needed to perform. Yes, you had to memorize a boat load of command line syntax because the mysterious book appeared and disappeared as it desired, but you never felt limited rather you just felt a need to search for the right command.
Enter the age of the personal computer. For simplicity, the command line went away. The mouse was born. There was nothing more entertaining than watching grown men in a room holding the mouse with both hands tightly but gently trying desperately to get that arrow moving in the right direction on the screen. “This mouse thing will never catch on” they grumbled. Suddenly the command line was gone, and menus or buttons presented to us. These were your options. Your only available commands. It didn’t take long before I missed my giant 3-ring binder of commands that gave me all the power.
Over time we became to believe that only the commands we could see were the ones of importance. We would become less and less frustrated at not seeing the things we needed. We are restrained by choices of actions presented. Our perception came to be that if it wasn't presented, it wasn't available.
So let’s take this into the modern smartphone age. The other night friends and I were out at a restaurant having a great conversation. The restaurant was closing because it wasn’t that busy and the owner wanted to call it a night. We asked each other the question “let’s continue this conversation – where should we go?”. We all pulled out our smartphones pulling up Google, Yelp, and the other thousand apps on our smartphones looking for a place that was open late. This searching went on for 15-minutes or so. Now I can be a bit impatient with technology and frankly don’t always find it of much help in situations like these. I quit my search letting the others wade their way through the digital data flowing around with smartphones. Then I looked up.
A beautiful park lay right before our eyes across the street, and we didn’t even see it. We believed our only options to find some place were those our smartphones provided. Did those applications tell us about the park? Not one. How about that food truck with the fabulous desserts? Nope. Not a single one. Our illusion of having choices was broken. Sure we got a lot of options, but it was all about the pictures of the menu or comments from other people that distracted us from answering the exact question “Where should we go to keep talking?”. The menu or interface design didn’t answer our actual question at all. It created the illusion of choice by presenting a small subset of options. All said and done the park was bug-free which is a miracle in Minnesota some evenings. Dessert and conversation continued for hours in the street lamp lit park.
As business analysts or designers, it is easy just to limit user choices to a few as possible to send them down a well-defined and perfectly groomed path. But does that answer their question? How many times have you wanted to say “Siri – lead the way to a great evening with my friends!”. The response from Siri is, “I’m sorry I don’t’ understand what you are asking”.
There are a thousand paths to getting or achieving something. No matter how hard you try to make it simple, it just winds up being even more complicated. Or worse the real thing you need is hidden somewhere because someone felt it wasn’t’ important enough to warrant a button. Some of the best interfaces look very simple on the front end and have a rich set of commands just slightly inside of the interface. As a business analyst and designer, we need to give our users or community a rich experience with our application. Are we the illusionist – forcing users down only one path? Our accounting system has several ways in which to generate an invoice. From a customer contact screen, main menu, sidebar and I’m sure more options remain hidden in the accounting interface. As I watched the finance, customer service, and sales people utilize the user interface with the simple task of generating an invoice, I noticed something important. Not everyone went about taking the same path.
Sales people always went to look at the customer inquiry screen first before generating an invoice. Individuals and their contact information were more important to them, and they would update it before moving on to creating an invoice. Customer service created invoices from the order screens as they were more focused on shipping products. Finance folks just clicked on the main menu option.
Know your users. They each have a story and a way of performing tasks that make sense to them. Think about their “persona” and what they need to accomplish. There is no single path to creating an invoice. Develop a list of capabilities and make sure they are not “hidden” from view. If it all doesn’t fit on a screen, find ways to expand the options for display when requested. Don’t fear including two buttons “Create Invoice” and “Add Invoice” which go to the same screen if it makes more sense to a broader audience of users. It is more about clarity for your users then consistency in terms.
What has a dinner in the park taught me? Smartphones are not as smart as we think they are. Everyone thinks they have choices, but don’t always see the most obvious choice because the choice is not presented in a way the user would understand. Question the choices presented and determine if they are the only choices.
Yes, I still miss my green screen terminal. CMD-1 key forever will mean “useless” help, and a blinking green bar on a black screen will always be a symbol of the endless possibilities to mistype ridiculously long string of text that doesn't make sense to anyone. And that huge 3-ring binder filled with commands-a-plenty works damn good propping the door open.
For more good stuff on business analysis and leadership, check out the blog at Bob the BA.
Pablo Picasso and Scope Visualization
Scope – the last frontier. We are on a mission where no business analyst has gone before. To explore strange new diagrams and to have the project scope clearly understood. Extra credit to those who remember which TV show that was from! Scope and context are the number one reason business expectations about a project are not met, and projects fail.
Let’s face the reality. Projects today are more complicated. In this integrated and connected world of systems long gone are the days of the quick and easy change. Our organization’s architectural diagrams look like the tombs of Egyptian Pharaohs. Symbols and shapes connected by lines that fill the wall of an entire room. Even trying to explain the diagram to someone can take days.
Projects now require more involvement by more people. Our systems and processes are so complex and integrated it’s too difficult for one individual to understand them all. Stakeholders are flung across the globe speaking many different languages. Top it off with organization’s taking on hundreds of projects at the same time. Keeping track of each project’s scope and impacts to the organization are difficult to comprehend. It’s no wonder why understanding the context of a project’s scope is the number one reason why projects fail to deliver value. They lose sight of the project's vision and goals in our complex systems and processes. Everyone is one a different page. We wind up spending a lot of time trying to get stakeholders, sponsors, and team members to have a clear understanding of scope.
So it’s no wonder that scope and context are the number one reasons projects fail. How can you get an entire project team moving in the right direction? Not understanding the scope and context of a project leads to all sorts of time being spent on just figuring out what we are trying to accomplish with a project.
So how do we get everyone on the same page? By that, I mean the same page in the same book!
It’s time to visualize scope. Scope places the boundaries around where the entire project team will work. Bust out that context diagram. Getting a clear common understanding of scope and business expectations leads to better projects that deliver real value. Is that user story a complete representation of the project boundaries or scope? Maybe not. The EPIC or a bunch of user stories combined would be closer to the bulls-eye. A picture is worth a thousand words. Visualization of scope is worth its weight in platinum as it creates the vehicle to ensure a common understanding of the project scope.
Scope visualization isn’t just about a context diagram. That’s certainly a great tool, and I blogged about it previously. Don’t get me wrong – I love my context diagrams. Pushing the envelope a bit, I have used infographics to display project scope in place of context diagrams. In a recent server upgrade project, I was updating the operating systems and consolidating over 1,300 servers. Sticking 1,300 servers on a diagram was an exercise in futility. There just isn’t a big enough piece of paper to display them all. So I pictured things at a higher level. I presented each server farm as a farm – yup cows and red barn with Farmer Joe. The size of the farm was based on the number of servers on that farm. Server farms were in specific locations, so this gave the project team a visual representation of which sites were going to be impacted more heavily. All of this was based on estimates from doing a high-level scan. Remember context is high level.
In each barn was an icon that represented a group of servers. There were three groups: leave it alone, upgrade it and consolidate then retire it. I didn’t have exact numbers or server names at this point, but I knew the servers would be divided into those groups by talking with stakeholders. Servers were put into groups based on our best guess.
In the kickoff meeting, this was a great tool. Sponsor and stakeholders understood in the scope of the project. Yes, they wanted to know more. Everyone wants to know the details, but we were just starting out. Everyone walked out of the room with a pretty good understanding of the scope and estimated size. Many were surprised at the volume of servers in each farm. Overall the infographic did an excellent job of setting the stage for the project visually. All on one PowerPoint slide.
The idea of scope visualization is to present a single page to provide a high-level overview of the changes the project will make to systems, processes, and people. That’s no easy task. Taking the complex and making it simple is powerful. It creates a
The business wanted a global CRM solution, but all they got were pigeons and index cards. Yeah, that is why context is important.
Context doesn’t just talk about scope – it also sets business expectations about the outcome of the project. It’s important that all throughout the project to keep the communication channels open on what is happening with the scope and how the design is being implemented to meet the scope.
I take the concept of the context diagram a little farther than how most folks typically use a context diagram. You know me always pushing the envelope. Context diagrams usually explain the end state or the outcome of the project. They show the scope of a project outcome.
Building on a good thing, I like to build a context diagram of the current environment at a high level. Even at a high level, I’m often surprised at how differently stakeholders, sponsors, and team members view the current state. It’s a great tool to get everyone on the same page for the starting point. Having everyone on a different page for what we currently have will cause a few issues down the road in understanding the final destination. Knowing where you are starting from is a powerful thing when to explain where you want to end up in the future state.
Taking this concept even a bit further (and perhaps more uncomfortably) into the desired state. Not many projects look at the desire of the stakeholders and sponsors. The desire is stated in the project request form or project charter. The sponsor and stakeholders put together a vision of the expected outcomes in these documents. A context diagram of the project charter or request which elaborates the vision is a powerful thing. It ensures what is being asked for is understood.
Don’t re-invent the wheel. Many times I take the current state diagram and just highlight the areas that are changing. Use color to highlight the add, modify or removes based on the context diagram for the current state. Color visually explains where the changes are visualized to occur.
Now you may think I completely lost my mind at this point. Fear not I’m taking a step even further. I take the context diagram that shows the desired state (based on the project charter or project request) and determines what is feasible. Everybody wants it all but the teleporter to zap you across the globe for a break in Paris hasn’t been built yet. Reality always steps in and dictates what is feasible. Taking the context diagram I will highlight the areas that are NOT feasible. It’s a great way to level set the expectations of the sponsor, stakeholder and project team members.
So when in the project life cycle does all this context stuff happen? Ideally, it should happen before the project starts at a very high level. Wouldn’t it be great to start a project where everyone understood and was in complete agreement about the project outcome? You can bet it would save a lot of time running around trying to get everyone on the same page. Typically, the context is set at the start of the project.
As you move through the project, more and more understanding is acquired. Details need hammering out and there is ALWAYS change to the project. Has anyone ever worked on a project with absolutely zero change? If you have, you are leading a very charmed existence. I’m jealous. Context diagrams can help evaluate how a change would impact the project. So forget about laminating them and hanging them on the wall. They are living breathing documents that will change throughout the life cycle of the project.
The pitfall is that architects and others might expect diagrams that show the smallest of components. Don’t fall into that pit. Your job is to communicate the boundaries clearly but not make it so complicated a rock scientist from NASA can’t figure it out. Detail is important for design but scope context requires things to start at a very high level and be decomposed into more information. Context is simple with enough detail to make it clear.
Break out your inner Pablo Picasso and get creative. Find a way to display context or scope in a visually appealing manner. Color can help bring greater clarity. Highlight areas in different colors to bring focus to them. If a system is risky or substantially impacted by the project scope, highlighting is a technique to denote that risk. Black & White isn’t your friend. Studies have shown that color diagrams – even with a small amount of color – are more memorable.
Check out Bob’s blog for more good stuff on business analysis and sign up for our newsletter today. Bob the BA offers the Badass BA workshop and Enterprise Analysis workshop which covers this technique in more detail.
8 Ways to Be a Badass Business Analyst Employee
Being a badass isn’t about intimidation or trying to be something you simply are not. It’s about knowing who you are and using your strengths to drive forward. So let’s look at a few of the ways to be a badass in business:
1. Passion for Your Craft Is a Powerful and Infectious Energy
Showing passion for your work in always willing to learn more and explore new ideas in your profession shows you are a badass. A badass isn’t afraid to learn something new about their craft. Always be willing to step up to the plate and show what they are good at performing. Sitting back and doing just the expected is not the badass way. If you are amazing at drawing diagrams, then use them frequently in your work.
A few years ago I was managing several projects. Things were not going all that well on these projects, and I knew something needed to be done to get them on track. Holding up the schedule and pointing at it wasn’t solving the problems we were facing. I decided to explore different approaches and ideas by contacting others outside the company for their advice and doing a little reading up on handling scope problems in projects. I learned a lot of scope management techniques as a result of that exercise and was able to apply them to my project. My boss at the time noticed I went out of my way to figure out new approaches, and I was fearless in learning new techniques about my craft. By learning and stepping out to explore new ideas I was able to move the project forward and save the project from failure.
2. Keep Positive
Nobody likes a negative person constantly interrupting, jumping to conclusions and always complaining. Keep a “we can do this” mentality even in the toughest of times. The measure of a badass is in being able to be calm, think clearly and project positive possibilities. When the whole world is crashing down, don’t be the one saying “Well that figures.” Instead be the one saying “This isn’t the greatest situation, but we have some great opportunities here to make positive changes.” See the good in situations where others cannot. Be the person that says “I’ve got a few ideas that might help in this situation, and I would like to bounce a few of them off of you.”
One of the toughest projects I faced was working with remarkable requirements, but a development staff that either didn’t want to or just could not fulfill those requirements with the current system in place. The team quickly got very negative at all the challenges that we were having in development. Everyone’s attitude soured and nothing was getting accomplished. The project was on its way to failure. So I threw a pizza party. My entire team thought I lost my marbles, and it was time to call the men in white coats to pick me up. Pizza does wonders for putting a team in a better mood. I told the team I understood the situation was bad and acknowledged that the company wouldn't accomplish anything without their skill sets. I purposefully turned the conversation from a negative (What is going wrong?) and made it positive (What ideas do you have to make it better?).
This was no easy task. I had to work very hard to move everyone’s attitude toward the positive after months of being in the negative. I was direct in telling them “Nobody wants to work on a negative team – it sucks. What can we do right now to make this team more fun and productive?”. After that hurdle had been cleared, it got easier to involve everyone in making team changes and design changes to the project. I kept telling myself that no matter what happens I will remain positive. The team’s attitude evolved over time. Many team members and company leaders repeatedly said that they could always count on me for being positive and finding solutions to problems.
3. Know Your Craft and Tools
A badass doesn’t just stop learning the basics of their craft or tools. They are constantly expanding their toolset and keep current about their craft. It’s too easy to get comfortable and begin to feel there is nothing more to learn. A badass grabs any opportunity to learn new things.
In my past life, I was at a company where I was pigeon-holed. I did such a good job at data warehousing and reporting that no one wanted to let me try anything new or different. Damn, I was bored out of my mind because every day was the same thing over and over. Sure I was learning new things about data warehousing and reporting, but I never stepped out of that area into other areas. So I forced the issue a bit and shoehorned my way into a call center application. It made sense for me to pursue it because that new system would be feeding the data warehouse. I went a little further than just worrying about data and started moving into user interface design and workflow for the new call center application. It was a great experience to use the knowledge I had in data warehousing and reporting to build better user interfaces and business processes. After the project had been finished, I was seen as being useful in business process as well as data warehousing. The door opened, and I got the chance to work on a whole new set of projects. Don’t be afraid to step out of bounds – you just might be valued for it.
4. Make Life Better for Others
A badass knows that improving the lives of their team members by continuously being focused on improving the way things are done is important. Being innovative to solve problems the team is experiencing in the day to day operations is just as important as solving project problems. Process improvement is powerful. A badass understands it’s not about single glory but helping others to achieve great success.
You always hear “It’s not my job” especially in large companies with well-defined roles. A badass looks for ways to improve the working conditions and tasks their team performs. It can be a simple as creating a library of past project documents that can be reused or finding a new way to perform time reporting that is easier. Whatever it is, a badass is looking for ways to improve processes at every moment and isn’t afraid to suggest well thought out changes.
5. Know Thyself Well
Know thy strengths and know thy weaknesses. A badass is aware of their strengths, and they know their weaknesses and limits. In today’s corporate culture, we focus on weakness. By focusing entirely on weaknesses, performance appraisals have become more like firing squads. A badass knows to play to their strengths and to engage others to help them out with their weaknesses.
There are certain things I have discovered I’m genuinely bad at. Anything that involves molding clay into an object is bound for disaster. Both of my skiing trips ended in an uncomfortable tree hugging. In business I know I’m a driver – be quick, be bright and be gone. It wasn’t until half way through my career that I realized how that impacts others who are not drivers. By understanding how I lead and act, I was able to soften my approach and be more collaborative with others. My driver mentality is a strength that others recognize. I can snow plow through massive amounts of data to give clear direction. I communicate quickly and concisely on projects.
Play to your strengths at all times. If you know you are weak in an area, then go out and find someone who is strong in that area to balance you out. If you get the chance to put teams together, look at each others strengths and weakness to balance them all out. Forget about finding that perfect all around team member without weaknesses. They don’t exist.
6. Don’t Always Say What They Want to Hear
Being a butt kisser or yes man is not the path of a badass. If you are always saying what others want to hear from you, they will never fully trust you because they can’t tell if that’s what you honestly believe or if you are just being a parrot and repeating everything back to them. A badass understands that conflict is part of life, and sometimes you are going to have to say what doesn’t want to be heard.
The trick here is saying it without being annoying or a jerk. If there is an elephant in the room, then say there is an elephant in the room. A badass knows that hiding the obvious doesn’t make it go away but rather gives it greater power. Address it quickly and directly. Forcing the issue is a one-way ticket out the door. Follow the “Toot, Toot and Salute” rule. Bring it up once and if there is no response or disagreement then re-group your thoughts. Bring it up again and if there is still no response or disagreement, then accept it and move forward.
7. Ask Questions, Challenge and Dig Deep
No one likes to be challenged. It puts them on the defensive right away. A badass understands that challenging an idea is an art form and that challenging helps bring deeper understanding and meaning. A badass knows that without asking questions and digging deep, the entire problem cannot be understood fully.
Nobody likes to feel they are being interrogated. Be fearless but considerate in digging deep. Verify your thinking and dig deeper with “Help me understand” questions. Share what you have learned to validate it. Be appreciative of the different perspectives and gather them all up to see the greater picture more clearly. The most significant problems I created for myself was making assumptions and never validating those assumptions. You may not be able to validate or challenge at that specific moment. Write it down, reflect on it and determine if you need to challenge it. Challenge appropriately and thoughtfully. Step back and schedule a challenge at a later time.
8. Lead Even When Your Job Title Doesn’t
A badass leads even when it isn’t in their title or role. They had the initiative and don’t shy away from leading in their craft. They don’t wait for someone else to schedule the requirements meetings, they step up to the plate and schedule them.
In the many times, I have played the role of the business analyst I’ve stepped outside my role a bit. I’m probably more comfortable with that then other business analysts in that I have been a project manager. My favorite is when I’m told how long it will take to gather requirements. You know those meetings were without being consulted the project manager has decided how long you as the business analyst will take to gather requirements and complete the design. When I’m in the business analyst role, I often will put together a requirements work plan outlining the steps that will be taken to elicit requirements and build the design. I review it with my stakeholders, project team and sponsors. This runs face first into the project managers desire to create and control the schedule. By gaining common agreement on tasks for the requirements and design process, the schedule can be more reasonably created which in turn helps the project keep to its timeline and budget. Is there a negotiation? Oh yeah – there will be lots of negotiation with the project manager, sponsors, and stakeholders on what will be done and what won’t be done. Step up to leading the task and schedule you will be expected to adhere to for the project.
For more good stuff on business analysis and leadership, check out the blog at Bob the BA.
Applying design thinking makes us better business analysts
The International Institute of Business Analysis defines in its “Business Analysis Body of Knowledge” (BABoK) that business analysis is “the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders”. To fulfil this task to a good standard business analysts require, among others, well-developed analytical and problem solving competencies. We all know that solutions we, business analysts, recommend to our organizations can stay within those organizations for quite a while. BABoK, in “The Underlying Competencies” chapter, provides a description of the behaviors, characteristics, knowledge and personal qualities that support the practice of business analysis. This chapter stresses the importance, among other aspects, of analytical thinking. However, is relying on analytical thinking sufficient to provide organizations with sustainable solutions?
Is analytical thinking the most important skill for business analysts?
On the one hand, the job title covers it all, you might say: business analysts must possess strong analytical capabilities; analytical capabilities that include the process of gathering information relevant to the business situation under investigation and identifying key issues related to this information. It also requires the business analyst to compare data from different sources/stakeholders, identify possible cause and effect patterns, and draw conclusions from these datasets to arrive at appropriate solutions. Analytical thinking is, in other words, a process of logical reasoning that converges on one “correct” answer based on the facts we discovered in our analysis. It can be compared with finding the answer to a question: what is one plus one? The correct answer is: two.
On the other hand, the world is changing at a rapid pace. The VansonBourne report, “The IT Complexity Challenge”, from October 2015, concludes that organizations have an increasingly difficult task trying to keep up with the introduction of new technologies and services as well as maintaining existing ones to a high standard to maximize the value gained. These changes in organizations are characterized by high complexity levels and are difficult to solve for many reasons: incomplete or contradictory requirements, the number of stakeholders and opinions involved, and the interconnected nature of these problems with other problems that exist in the organization. These problems are also referred to as “wicked”.
The definition states that wicked problems are ill formulated where information is confusing, where there are many clients and decision makers with conflicting values. Solutions to these problems are not right or wrong, they are simply “better”, “worse”, “good enough” or “not good enough”. The acceptance of solutions lies in the hands of stakeholders and their values and perspectives on how the solution should work/look like. We, business analysts, have to deal with wicked problems on a regular basis, don’t we?
Wicked problems vs analytical skills
In this complex landscape of wicked problems it may not be enough for a business analyst to rely solely on his/her analytical skills to provide satisfactory solutions to organizational challenges. The traditional analytical thinking may be inefficient due to the cumbersome process of gathering information, incomplete and contradictory datasets, hidden agendas of stakeholders and other social aspects of the situation. Alternative approaches may be required
Stepping out of the comfort zone: introducing design thinking
Design thinking isn’t anything new; it has been used for years, as already mentioned in the previous blog. However, the applications of design thinking have evolved over the last couple of years and its usage has expanded to business, in the broad meaning of the word. It has proven to be suitable to provide satisfactory solutions to the “wicked” problems we mentioned earlier. Design thinking is characterized by a recognition of the importance of good understanding the problem to be solved; a deep sensitivity to what stakeholders really want and, more importantly, what they choose to do in day to day life; a willingness to experiment, learn and refine; a focus on whole systems, not just on their parts.
To achieve that, design thinking employs concepts of divergent and convergent thinking, prototyping and iterations to problem solving. Through fostering curiosity, a holistic approach to business situations and focussing on stakeholders, the business situation is explored. This is required to develop a better understanding of current reality. Hypotheses are created that could work in an effort to find one that fits the problem situation. The divergent thinking intervenes with convergent thinking, narrowing these possible solutions down to some candidate solutions, which are further prototyped and evaluated. In this iterative way the best suitable solution is defined.
Design thinking lies close to our human “problem solving” nature. In the 80’s the Microelectronics and Computer Technology Corporation (MCC) looked into how people solve problems. The results are presented in the figure below:
Figure 1: Pattern of cognitive activity – the “jagged” line [source: http://cognexusgroup.com/]
The red line represents a linear approach from our work instructions or process descriptions, which prescribe how we should tackle a problem situation. The green line shows how people really work. The lines differ quite substantially, don’t they? This experiment showed that, faced with a novel and complex problem, people do not simply start by gathering and analyzing data about the problem. Cognition does not naturally form a pure, complete and abstract understanding of “the problem”. It simply does not work that way. It also illustrates that problem understanding can only come from creating possible solutions and considering how they might work. These possible solutions trigger more questions about the problem and strengthen the need to understand what is really needed. This experiment supports the success of design thinking where exploration, ideation, iterations and prototyping help provide value to stakeholders. It is more in line with our human nature.
Applying design thinking makes us better business analysts
Design thinking and its techniques are very much applicable to business analysis. We, as business analysts, are quite often “wicked” problem solvers and help our organizations to change and adapt to a fast-paced world. The idea of divergent thinking to explore the problem and ideate many solutions (possible or impossible), and then convergent thinking to select the best solution direction, fits perfectly with what we are doing. Design thinking offers us tools that help us:
(1) deal with stakeholders and their opinions,
(2) validate whether we are on the right track, and
(3) find solutions that delight the stakeholders in the end.
Business Analysts should be top of mind
What is the role of the business analyst? A typical response to this question is that he is a bridge between IT and business. Often this view is reinforced by textbooks and training material covering the business analysis domain. The reality is that there is still much confusion about business analysis as a discipline.
In my opinion, this view is flawed, and it inadvertently leads to a limitation of how most business analysts see themselves. It renders them incapable of offering real value to the businesses they serve, and more importantly becoming top of mind to their business owners. I would argue that business analysts are a triangle connecting three parties: business, IT and the customer, instead of being a bridge connecting two sides.
In some cases, organisational structures further exacerbate the limitation of the business analysts’ ability to deliver value. This happens when business analysts fall within the IT reporting lines and get assigned to various businesses from time to time. This structure has unintended consequences. Business analysts see themselves as IT resources first, and business resources second. At the face of it, this might seem like an insignificant side effect. However, I would argue that it is at the core of the mindset that is adopted by the business analyst. It is responsible for the ‘us’ and ‘them’ situation where the business analyst refers to the business he is servicing as ‘them’, and the IT team to which he belongs as ‘us’.
So how does the business analyst become top of mind?
There is a definite need for the business analyst to be closer to the business and to be a true ambassador of the customer. I have seen that in most cases, business analysts who report to IT struggle to make a ‘business’ mindset shift. Wearing the business hat and ultimately that of the customer within the IT structures often makes the business analyst feel like he is betraying his IT colleagues.
Confidence is required for the business analyst to change the reporting dynamic. Reasoning with the IT team as to why it makes business sense and not necessarily IT sense takes courage. Business may want to adopt a phased approach in rolling out a solution versus the IT team’s big bang approach. The business analyst will need to address this with the teams in a confident manner.
An essential area of understanding for the BA is the customer’s pain points and how a particular solution will solve them. Knowledge of the market, the client’s competitors and which projects will yield the highest ROI is a prerequisite. Questions such as which projects are strategic or need to go ahead from a compliance perspective, and how to reach a particular market need answers.
A business analyst may need to explain to the technology team why his business requires certain information from his customer or potential customer over others. A full understanding of the business rules is needed, for instance, an RSA ID field as a mandatory field but not a Passport field as an option. Alternatively, why one type of design will have an adverse effect on the customers’ user experience and possibly result in a huge customer drop off through the journey map.
It is an undeniable fact that business analysts should have a fair, if not solid, knowledge of what is going on in the technology space. Requirements will need to be documented and in turn translated into system functionality. The BA is likely to spend most of his time in system design sessions with the IT teams to bring these requirements to life. If the BA has no technical background, he is likely to end up frustrated when engaging with the system developers, solutions architects and the rest of the IT team members.
Having an understanding of IT will help to earn the respect of his IT colleagues as well as to gain acceptance. At the end of the day, real collaboration is necessary to deliver value to the customer.
Talking of value - never before has the demand been so high for businesses to deliver value to their customers using technology. The advances in mobile technology and the ubiquity of smart mobile devices has created an exponential increase in the demand for mobile apps as platforms to service customers. Organisations are almost forced to digitize their service offerings through mobile apps – or they will lose out to their competitors.
Moreover, techno-savvy customers are demanding convenience and searching for time-saving ways to get what they want. Services have also been commoditized and delivered via systems. The business analyst is required, now more than ever, to marry IT and business to enhance the customer experience through self-service channels via mobile devices and kiosks. Therefore, understanding the technical arena, while showing a solid grasp of the business has enormous benefits.
What skills should the business analyst have?
While the above criteria are crucial for the business analyst to master, there are specific skills needed to achieve top of mind status. The first of these skills is the ability to listen attentively in what is called active listening. To do this successfully, one needs to learn to switch off the internal monologue. This usually happens whenever we are listening to someone else. It requires attentive listening without thinking about your response while the speaker is still talking.
The value of getting this right is that it will allow the business analyst to pick up on and appreciate the nuances inherent in the priorities between IT and business. It is important to note that these parties have different mandates to carry out within an organisation. A common misconception is that IT should not or will not dictate to business. However, the reality is that if business has no clue of what is happening in the IT world, then this dictation happens all the time. A technically informed business analyst who actively listens to both parties stands a better chance at success.
Also, if inactive listening is applied then the finer details that inform the different mandates may be missed, and this might result in conflicts and confusion. Listening actively to both parties during the requirements elicitation and/or JAD sessions can save the business analyst much pain in the future. Active listening is not a talent, but a skill that can be learned and developed.
It is important to note that during system development, especially within an environment that uses a waterfall methodology, a lot of clutter and noise can easily creep in between the time of the initial request (from business) to the time of the final delivery of the solution (by the IT team). A business analyst needs to use active listening skills to identify what is said (to ask for confirmation), what is implied (to ask for validation) and what is not clearly stated (to ask for clarification) to remove this clutter or minimize its impact.
A business analyst tends to be a leader from the side meaning that no official authority has been given to lead within an organisation. However, coordinating and managing roles and responsibilities between the business, IT team and the customer puts a huge leadership role on his shoulders.
Good leaders rely on influence, and as such a good business analyst needs to develop and master this art. To be top of mind to his stakeholders, the skill of encouragement and influence may shift the viewpoint of others. However, the ability to change minds does not happen by chance; it comes from the respect which the business analyst has gained through demonstrating a strong understanding of the business and domain skills. The latter also builds confidence to educate his or her colleagues about the discipline of business analysis.
The ability to deal with conflict can also earn the business analyst more brownie points towards achieving a top of mind status. When conflict is not resolved within a project, it can add to delays and increased stress levels. Ambiguity can also create tension and conflict in a project. It is an expectation that while the business requirements from the business analyst should be devoid of ambiguity (especially in the waterfall driven environment), the business analyst should be able to handle ambiguity and make sense of it.
Proper stakeholder management also requires a careful study of his participants and engaging with them appropriately. It is not a one-size fit all approach. Knowledge of which stakeholders may throw a spanner in the works during that big walk-through session is necessary. Getting their buy-in before the meeting is just as important.
Some stakeholders require a one-on-one consultation before the big meeting; others are happy to know about your requirements during that big meeting. Some are satisfied with a one-pager or an email highlighting what you expect from them; others require the full story before the meeting. Some prefer a pictorial view of your requirements, while others would like a fine print.
Dealing with expectations efficiently will find the walk-through sessions a walk in the park!
Managing stakeholders go hand-in-glove with relationship building. The business analyst must realize that specification documents (whether as business requirements, functional requirements and even user stories) are not, and cannot be written in isolation. A business analyst who does this runs a risk of creating a ‘disconnect’ between himself, his business and the development team.
Furthermore, adaptability and flexibility together with knowing which skill to use and when are also essential characteristics. With good relationships, the business analyst can quickly put pressure on the delivery team, without alienating them, or begging them without feeling humiliated, and even convince them without offending them.
A business analyst cannot be top of mind without showing innovative ways of solving business problems. To do this effectively he or she needs to demonstrate an understanding of strategic objectives, i.e. why is his business going in a particular direction? Often, it requires a ‘big picture’ view which takes the business analyst from a departmental to an enterprise level. Presenting this big picture view builds confidence to identify the alignment between an individual project and what the organisation is trying to achieve.
With this comes the confidence to challenge the business if there is a misalignment regarding the organisational strategic objectives and the project. Arguing a case against a project that does not contribute value will put the business analyst in good stead with the business owner – especially after it has been proved correct by the lack of return on investment.
Lastly, nothing can replace passion, enthusiasm and dedication. These attributes cannot be measured, however, when they are not there – they are conspicuous by their absence! Business owners will notice a lack of passion for their work and a reluctance to do what is necessary. It is also self-evident when a business analyst only does the bare minimum. The business owner needs someone who can energize the team and ultimately go the extra mile!
Quick Intro to Decision Model and Notation - DMN
Decision Model and Notation in short DMN is a novel way to model business decisions. DMN allows capturing and modeling business decisions in a way that is easy to understand with business people and subject matter experts. It is a combination of:
- Decision requirement diagram – DRD
- Decision table
- Boxed expressions
- Friendly Enough Expression Language – FEEL
Decision Requirement Diagram (DRD)
This is a graphical model that allows modeling dependencies between input data, decision, business knowledge and knowledge source.
In DRD, the arrows show the dependencies between different nodes in the model. To put it in a simple way, you can read it as if the output result of some nodes will be passed as the input of the other nodes.
In the table bellow, all the elements on a DRD model are illustrated:
In decision model and notation, the Decision Table is a tabular form that models rules based on conditions and actions which they are also called inputs and outputs. Decision Table is the default type of modeling business rules in DMN. But if your tools support other ways to model business rules then you can freely use them along side with decision table.
In Decision model and notation (DMN) are a simple two column table and effective way to model business formulas, calculations, values and expressions. And then you can share them across multiple decisions and logic.
Boxed expressions simply allows modeling: constant, values, invocation, formulas… Boxed expressions allows putting together building blocks of logic (i.e. decision table, natural language, flow…) and reuse them over and over again.
Friendly Enough Expression Language
In decision model and notation, FEEL is an expression language for business people. FEEL define a syntax for expressing conditions, actions and formula. Consider FEEL like excel formulas that they allow you formulate your thinking about a domain in a context. FEEL is designed to allow ease of use by business people and subject matter experts.
There are benefits of using decision model and notation over the traditional business rules approach. In the business rules approach, very soon you start thinking about the business rules which they are more about the logic implementation. But decision approach provides a more high-level abstracted layer that allows you to see the big picture first rather than diving deep into implementation and losing the context and overview of the solution.
This change of approach:
- Allows scaling business rules in more manageable, reusable visual approach across applications and processes.
- Allows better communication between business, domain experts and IT by enabling a productive involvement of business people and subject matter experts.
- Allows clearly define decision boundaries and expose the decision as a service with a click!
If your tool supports simulation and execution, error checking at design time and runtime with debugging capability then you will not miss anything from business rules approach, but also will have a better way to reuse and scale your business rules in a systematic way.
Submitted by: FlexRule
Replacing the Sprint Review Meeting with BMLs
Like most Scrum teams, we held “Sprint Review Meeting” every two weeks. We would gather as a team to demo what was recently built & receive feedback. Although it was a great opportunity to showcase recent work, we identified a number of problems with “Sprint Review Meetings” for our mature product:
1. Stakeholder attendance was poor. Stakeholders saw the Sprint Review Meetings as a technical show & tell. The demos often didn’t work fully & business value wasn’t necessarily communicated.
2. Because developers demoed the work, it put disproportionate pressure on the development team. We presented recent work & we often had problems with test environments/connections/mock data etc.
3. More generally – the development team wanted regular updates from the product team. Our retros identified a need for the product team to provide regular updates about recent features; did a recently released feature meet our hypothesis? What did we learn? Will we iterate? How did it impact our quarterly OKRs?
4. Sprint Review Meetings felt like a conveyor belt. We would demonstrate work, get feedback about quality, and then watch it leave the factory. But we wanted to learn how customers actually used the new product. We wanted external as well as internal feedback.
Build, Measure, Learn (BMLs) sessions
To address the above issues, we replaced Sprint Review Meetings with “Build, Measure, Learn” sessions. As advocates of the Build, Measure, Learn approach – we were keen to review recently released features with the team. We launched features every 2 weeks – so the natural cadence was to report on features at the end of the following Sprint.
We created “Build, Measure, Learn” sessions. The basic format is simple:
Every 2 weeks. At the end of the Sprint. Replaces the Sprint Review Meeting.
Team (Product, Devs, UX) & Stakeholders.
The session is divided into two sections:
1. Build = demo from the development team about what was built during the Sprint. It’s a chance to get feedback from the Product Owner/Stakeholders.
2. Measure/Learn = product reporting back on stats/usage/insights of recently launched features. Typically on features & changes launched 2 & 4 weeks ago. This provides an external feedback loop.
The Measure/Learn section became as valuable as the demo section. It also provided practical breathing space for setting up/fixing demo’s – if we had problems we would start off with the Measure/Learn section 😉
As with the Sprint Review meeting – this section was the development team demoing what was built during the Sprint.
This was an opportunity for product/stakeholders to provide feedback and ask any questions. Changes were noted by the BA and put on the product backlog.
It was also an opportunity to praise the team & celebrate success.
In the Measure/Learn section the BA or Product Owner would cover the following areas:
1. General product performance: how we are performing against quarterly goals/OKRs
2. For each recently released feature:
a. Present the testable hypothesis
b. Present the actuals. Key trends/unexpected findings/verbatim feedback from the audience about the feature
c. Present key learnings/actions: Build a v2/pivot/stop at v1/kill the feature?
3. Wider insights (optional):
a. Present recent audience research/lab testing
b. Present upcoming work that UX are exploring & get feedback on it
We found that BML sessions were a great replacement to Sprint Review Meetings. They ensured we kept the measurement & learning part of the lifecycle front and center in the team. The Measure/Learn section also ensured we reported back on business value regularly.
1. Learnings/insights about recently released features were shared with the team - this kept us focused on our original hypotheses and business value. It enabled us to discuss the learnings based on external audience feedback.
2. Encouraged a shared sense of ownership about the end of Sprint session and the performance of features
3. Increased stakeholder attendance & stakeholder engagement as there was a focus on audience feedback and KPIs
4. We were still able to demo the newly developed features & get Product Owner/Stakeholder feedback
What is good enough when it comes to a requirements management tool?
At Seilevel, we updated and re-published our Requirements Management (RM) Tool Study this past year, looking at over 150 tools and over 200 criteria. We did this in phases with the subset of tools making it though each phase getting smaller and smaller until we ran 21 tools through the full evaluation criteria to rank them. This tool study is a great resource if your company is looking to implement an RM tool for the first time.
But what about if your company already has an RM tool in place or has multiple that you need to decide between? The tool study report doesn’t really address how a company can look at their current tool or tools to see how they compare and if they would meet the needs of the company. You could, of course, just take the total scores and ask which one is higher or how your tool’s score ranks, but that doesn’t necessarily mean that the tool you have in place wouldn’t be “good enough” for your company’s purposes.
So, what does it mean for an RM tool to be “good enough.” Well that depends. It depends on what your requirements methodology emphasizes and what is important to ensuring you minimize the risks to your projects through the use of the tool.
Because “good enough” varies from company to company, I took our RM tool study and categorized each of the 200+ criteria into one of ten categories, or features. With these features, I then created a capabilities dashboard that shows a heat map of how each of the top 21 tools fared in the 10 features as a percentage of the total points available in that feature. With this view, you can either find or add your RM tool and see how it compares in specific categories to the other tools we evaluated to determine if the tool you have is “good enough” for your process.
The 10 features are:
- Requirements Specification and Prioritization: Can you add, edit, delete and prioritize requirements easily?
- Traceability/Dependencies: Can you create relationships between requirements and change the data model to reflect the traceability needed in your organization?
- Stakeholder Management, Review and Collaboration: Can you give feedback on requirements or initiate workflows to approve requirements?
- Change Control: Can you baseline requirements, track changes after a baseline or revert a requirements set back to a baseline?
- Visual Modeling: Can you create and edit models in the tool or link requirements to visual models?
- Import/Export and Reporting: Can you import/export to and from Word, Excel, Visio or other sources and can you report on the requirements, models or subset of either group?
- Requirements Process Support: Can you set up your own templates and object types to support a methodology with things like checklists, issues, risks or constraints?
- Task/Iteration Management: Can you track development tasks on requirements, set release or iteration dates or create agile burndown charts?
- Licensing, Support and Tool Administration: How flexible is licensing for the tool, are there adequate support materials and how difficult it is to maintain the tool?
- Scalability, Integrations and Ease of Use: How intuitive is the tool, can it scale and what integrations does it offer?
With these ten buckets, the heat map is shown below (click to expand). Typically, you would want to narrow in on a few tools or a few features. For example, if you know you have JIRA in place today, but Traceability and Dependencies are the most important feature to your organization, you would see that JIRA only received 60.4% of the total traceability and dependency points. Or if support of visual modeling and requirements process is most important to your organization, you might narrow down your list to TopTeam Analyst, Modern Requirements Tool Suite and Blueprint.
With this view, you can add one more dimension to your RM tool quest and maybe answer the question of “Is our RM tool good enough?” If the answer is yes, you have the heat map to socialize that message and if the answer is no, you can use this to help build the case for a new RM tool.
Step into Right Priority
The previous two posts in the Requirements Prioritization series, we discussed the honest difficulty that stakeholders face when asked to simply prioritize requirements, and how to overcome this obstacle by using prioritization parameters. If you have not read these posts, I recommend you read them first here and here.
In this post, let's discuss some of the requirements prioritization best practices. I will attempt to organize these best practices based on when these will be applied during requirements engineering journey. So here goes...
Requirements Planning Stage
- Determine the Stakeholders: Discuss with the Sponsor and other key stakeholders to determine a cohesive set of stakeholders who will participate in the prioritization exercise. Remember that it is totally possible (and acceptable) that more stakeholders might be added to this set. This information will straight away be updated to your RACI matrix.
- Tell 'em how it's done: Right at the beginning of your project, when you create (or tailor) your Requirements Management Plan, socialize your prioritization plan (among others) with the stakeholders. Help them clearly ‘get’: the Prioritization Process (we will discuss the process in detail later in this post), the Prioritization Parameters (i.e. the Glasses), their weights, the Rating Scale (all of which we will determine in collaboration with the stakeholders) and the Frequency of prioritization. You may use a spreadsheet (download) to facilitate this discussion and the prioritization exercise.
- Prioritization Parameters: Present your recommendations to the stakeholders on the Prioritization Parameters that makes sense for your project. Explain to them what each parameter means, and more importantly, why you think they are relevant to your project. Ensure you achieve consensus among stakeholders and have their approval.
- Parameter Weights: Not every prioritization parameter will matter equally to the stakeholders. For instance, most stakeholders will want Business Value to matter more than, say, Implementation Difficulty; thus Business Value is assigned more weight than Implementation Difficulty. There is no limit to the number of parameters, although more the parameters, higher the time required for prioritization. Optimally, 5 or 6 is a good number.
- Rating Scale: MoSCoW (Must, Should, Could and Wont) is a popular rating scale. You could chose a HML (High, Medium, Low) or a vH-HML-vL (v stands for very). I personally would use a numerical scale, say a 1-5 or a 1-10 scale. This provides more flexibility in assigning minor variations in priority. Even if you use a non-numerical scale, like MoSCoW, you must assign a numerical value to M, S, C and W. This is to ensure you can calculate the weighted average and derive the overall Priority (see spreadsheet)
Remember, while walking the stakeholders through the above, your tone and tenor of presentation is to ‘collaborate’, and not ‘dictate’. You must be open to customize any aspect of prioritization – stakeholders involved, prioritization process, parameters, weights, rating scale, and frequency
Requirements Prioritization Process
Step 1: Schedule a workshop inviting only the relevant stakeholders. Share with them the prioritization spreadsheet in advance. If you are using a requirements management tool, which has built in prioritization capability, provide access to this tool to the stakeholders. This helps the stakeholders prepare for this workshop (although you should not expect all stakeholders to be prepared. In they are, it is a bonus!)
Step 2: At the beginning of the workshop, ensure that all stakeholders are aware of the prioritization plan (described to them during the requirements planning stage). If not, repeat the plan and ensure all stakeholders are on the same page.
Step 3: Focus the stakeholders on the requirements being prioritized. Typically, prioritization workshop follows requirements sign-off workshop. You would therefore assume that the stakeholders already have an uniform understanding of the requirements. However, at this point, it is a best practice to ensure that there are uniformly understood by all stakeholders.
Step 4: Direct the stakeholders to the first prioritization parameter. Have them go through every requirement and provide their individual rating based on the first prioritization parameter.
Step 5: Once everyone completes Step 4, consolidate the ratings from all stakeholders and derive the average rating for each requirement. Request the stakeholders to review the average rating, and compare it against their own individual rating. If there is too much deviation, request them to surface their concerns. Facilitate an open and free discussion, and forge consensus among all stakeholders.
Step 6: Move on to the next parameter, and repeat Steps 4 and 5 until all the parameters are covered.
Step 7: Derive the overall priority. Ensure that all stakeholders approve the priority.
That’s it…you are done. You may repeat the prioritization exercise as many times as you wish during the project. In fact, projects following Agile methodology require that the user needs are continuously prioritized.
In this three-part series on requirements prioritization, we discussed why stakeholders find it difficult to prioritize requirements, what you can do as a Business Analyst to help them and how exactly you would go about helping them.
Let me know your views and feedback.
Modeling your way to a great backlog
If you’re a business analyst whose company recently made the move to agile, you may be wondering where you fit in when there is no business analyst role. Or maybe you made the move to be an agile business analyst or product owner but don’t know how your traditional business analyst skills figure into this new agile world. Well the good news is that even in agile frameworks with no official business analyst role, business analysis still needs to be performed for every product so that we know we’re building the right thing. It may be called something else and we may do it differently, but it is still a vital part of the agile process.
With this post, I want to talk about one piece of business analysis - visual modeling - and how it fits into agile and building a great backlog. In waterfall projects, the business analyst will typically gather all the requirements up front (prior to design and development) utilizing visual models to enhance and give context to her requirements. In agile, we do everything with “just enough” detail, “just in time” for the development team to start working on a given requirement or user story, so many people have taken the route that the user story along with conversation is enough and we don’t need visual models anymore. This couldn’t be more wrong! Especially with so many large, global companies moving to agile and having distributed team with lots of dependencies, visual models can help bridge communication gaps that co-located agile teams can cover with conversation.
So, why visual models in agile? Visual models arguably are even more important in agile projects than in waterfall projects because there is a low cost to build or change them. They are easy tools to use to gain understanding between the business stakeholders and the development team without having to spend a lot of time writing requirements or user stories. Additionally, visual models allow the product owner or business analyst to view the whole product and vision while focusing on a sub-set for delivery - enabling the product owner to deliver the most value the soonest. Visual models are a great supplement to the backlog and user stories to gain a richer understanding of the product and the needs of the users. They also help the product owner or business analyst find missing stories and acceptance criteria.
Which models are best in an agile process? We have 22 visual models in RML®, but not all of those are useful all the time, especially on an agile project. However, I’ve found that there are about 5 models that are used on almost every agile project I’ve worked on. Let’s walk through each one - in this blog post, I’m just going to give an overview of each visual model, but you can find more information in the links below.
Business Objectives Model: The business objectives model tells the team why they are working on a project or building a product. It is similar to a product vision, but gives concrete objectives that we want to solve with the project/product. On agile projects, this is probably the most important model because the product owner or business analyst should be tracing every single user story back to the business objectives model to ensure that we are only building what is needed and useful to the user.
Process Flow: Process flows detail out a business process from the user’s perspective. They can be at multiple levels (typically L1, L2 and L3 - starting at the highest, most-abstract level and working down in detail) and so are great for agile projects! At the beginning of a project, the product owner or business analyst can define the L1, high-level process to identify epics or features, and as iterations progress, can dig deeper into L2 and L3 detailed process flows. Each step in a lower level process flow is likely to be one or more user stories.
Feature Tree: A feature tree is a visual model that lists out all features for a product/project in a hierarchical tree format. In agile, this is a good tool to keep up with requested features because it is easy to update. By color coding or making important features closer to the “trunk” of the feature tree, you can easily show iterations or releases.
Business Data Diagram: The business data diagram shows all data objects in a project or product and how they relate to each other. On agile projects, this serves two purposes: as a catalog of the overall data needs (hard to show in a user story) for use in building databases and as a source of acceptance criteria to enforce the relationships between data objects. This is a lower level model and may be started in a sprint 0, but would need to be kept updated in subsequent sprints.
Decision Tree or Decision Table: Finally, decision trees and decision tables detail out system logic and how the system should respond to various input decisions. These can be used to expand a given user story with decision logic or can be used as the acceptance criteria themselves. Since one of the most common ways of writing acceptance criteria is the “Given, When, Then” format, this lines up nicely to decision tables, where the “given” is a precondition, the “when” is a trigger or decision and the “then” is the outcome. Decision tables ensure that every combination of decisions and outcomes is considered, so when using these for acceptance criteria it is clear to the developers and testers what should happen in every instance.
These are the visual models I’ve found useful on my agile projects, which ones do you use?
Glasses for Priority
- I reasoned that stakeholders only appear to be uncooperative in the prioritization process. In reality, they are unable to prioritize requirements because they cannot see one requirement more or less important than the other.
- I urged you to ponder whether it could be due to BA's drawback that s/he is unable to get the stakeholders to really see priority among requirements.
In this post, let us consider a few 'glasses', which will enable the stakeholders to see the relative importance among requirements. Here you go:
Glass #1: Business Value
Business Value is viewed in terms of faster, better and cheaper. Wearing the Business Value glasses, the stakeholders determine the degree to which one requirement contributes to the business to become faster and/or better and/or cheaper relative to the other requirements. Higher the business value offered by a requirement, higher its priority. Typically, business stakeholders weigh in on determining the Business Value of requirements.
Glass #2: Business Risk
Business Risk is viewed in terms of what can go wrong in the business. This must not be confused with what can go wrong to the system (that is implementation difficulty or technical risk). For e.g. introducing an interface between two systems will lead to a bunch of data entry operators losing their jobs. This is a risk although its impact depends on the risk appetite of the organization.
Wearing the Business Risk glasses, the stakeholders determine the degree of risk that the business would face because of a requirement relative to the other requirements. In other words, if that requirement was dropped, then the risk to the business is reduced.
Applying the general principle of fail early, fail quick when the cost of failure is low, higher the business risk posed by a requirement, higher its priority. However, this depends on the organization's risk appetite. Some organizations may choose to do the opposite. Typically, business stakeholders weigh in on determining the Business Risk posed by requirements.
Glass #3: Technical Risk
Technical Risk is viewed in terms of what can technologically go wrong during the implementation of the solution. Wearing the Technical Risk glasses, stakeholders determine the degree of technological risk posed by a requirement relative to other requirements.
Again, based on the general principle of fail early, fail quick, higher the technical risk posed by a requirement, higher its priority regardless of the risk appetite of the organization. Typically, implementation stakeholders like architects, designers and developers weigh in on determining the Technical Risk posed by requirements
Glass #4: Implementation Difficulty
Implementation difficulty is used when demonstrating quick success is important. In such situations, implementation stakeholders determine those requirements that are easiest to implement relative to other requirements. Lower the implementation difficulty of a requirement, higher its priority
Glass #5: Minimum Viable Product (MVP)
MVP is used to determine those requirements without which the product would simply be incomplete. You wouldn't purchase a car without breaks or mirrors for instance, would you? But you might consider buying the car without, for instance, automatic windows.
Thus MVP Requirements must have higher priority over other requirements. In this context, requirements that cater to a regulation must be a part of MVP.
Glass #6: Dependent Requirements
A requirement that by itself may not be treated as high priority, but if other high priority requirements are dependent on this requirement, then it is also provided high priority.
The above are some of the key glasses that can help stakeholders get over their "all requirements are important" syndrome and truly participate in the prioritization exercise. By the way, I am sure you realize that I only use the term "glasses" to extend the analogy from my previous blog. The proper term for glasses is "Prioritization Criterion or Parameter"
Are these the only glasses/parameters that you must use? No, absolutely not. In fact, some of the above parameters may not even apply in your project situation. You may find it necessary to use entirely different set of parameters. As a BA, you must first collaborate with the stakeholders must arrive at a set of prioritization parameters that are relevant to your specific project situation.
In my next blog, I will write a detailed note on the best practice process for requirements prioritization. Till then, I would love to read and respond to your comments...keep them coming!
All requirements are important!
I was running a meeting with a few stakeholders. I was imploring them to indicate the relative importance of requirements, but was hitting a brick wall; they kept insisting, "They all look the same to me. All requirements are important. They all are must-haves."
I tried to reason with them multiple times over. There are just too many requirements, and cannot possibly implement all of them in the available time and/or budget. But they kept insisting that all requirements were indeed important.
I thought to myself, “Why are these people being so difficult? Why are they deliberately feigning ignorance?” I literally felt like tearing my hair out!
Have you been in this situation? I bet you have. Why is prioritization such a hard exercise? There must be a better way, right?
Let's rewind a little bit and review how we usually begin a Requirements Prioritization meeting: "Thanks for accepting this meeting. The purpose of this meeting is to prioritize the requirements. We are going to use the MoSCoW technique. Let us walk through each of the requirements and collectively decide whether this is a M, S, C or W."
Sounds familiar? If not exactly as stated above, it could be some flavor of the above. Instead of M, S, C or W, it could be some other rating mechanism. But, for the most part, the spirit is essentially the same.
My hypothesis is that, with the above expectations, stakeholders truly are not able to differentiate relative importance among requirements. They aren’t being difficult at all; they honestly cannot prioritize. Let me give you an analogy:
Imagine being in a corporate conference room. What can you find in there? Whiteboard, video con equipment, large table, uniform looking black chairs around the table, etc.
Suppose I ask you to arrange the chairs around the table in the decreasing order of blackness, what would you say to me? I imagine you would say, “They all look the same to me.” Exactly the way requirements appear to the stakeholders – all the same.
Suppose I give you a pair of glasses. Not any ordinary pair of glasses, but one that has spectrograph capability, and a display on the top right corner. When you wear this glass, and look at any object, a graph of various colors on the object along with their intensity represented numerically is displayed. Now would you be able to do arrange the chairs in their decreasing order of blackness? Sure you would!
Few questions to ponder over:
- You weren’t initially able to arrange the chairs in their decreasing degree of blackness. Is that your fault? Does it indicate your weakness? Or does it point towards my weakness of not knowing how to enable you to do that activity?
- Is it the stakeholders’ fault that they aren’t able to prioritize the requirements? Or is it my drawback as a BA that I wasn’t able to get them to “see” the relative importance among requirements?
Think it over. I would love to hear your comments. Let’s talk and engage in a productive discussion.
Meanwhile, in my next blog, I will write about the various glasses that you can provide to your stakeholders to get them to truly see the relative importance among requirements.
How A Dentist Appointment Made Me A Better BA
My youngest daughter was scheduled for her first dentist appointment. She couldn’t contain her excitement. She had her stuffed dog, dentist-visiting attire and bright, sparkling smile ready for the event. She was ready to go. Little did I realize that not only would my daughter come away with a clean-bill of dental health, but that I would come away a better business analyst as a result.
1. No pre-conceived notion – My daughter was excited with no apprehensions and no self-fulfilling prophecies to sway her. She had no idea what it was going to be like nor did she hold any opinions on the matter. She just knew that her older brother and sister went regularly and now it was her turn as a ‘big girl’ to go to the dentist! Kids are not born with pre-conceived views of the world. Most of what they experience is a surprise (pleasant or unpleasant) and an adventure. As adults, we have lived through many different experiences and as such, some of us dread going to the dentist. As a business analyst, we deal with pre-conceived notions on projects all of the time. End users, sponsors, subject matters experts all have some sort of view or opinion on the purpose (goal) of the project. Some views are positive (end users are really needing this enhancement) where other users are skeptical or out-right negative/cynical about the purpose. As a business analyst having a view or opinion of the project is ok, but I find one is far better served to suspend all judgement…the success of the project increases when the business analyst leaves his\her views at the door.
2. Curiosity - One of the results of my daughter’s experience was a ton of questions directed at me. “Why do you have to sit in a long chair?”, “Why does the doctor wear a mask?”, “Why do I need my teeth cleaned?”, “why?”, “why?”. Some of her questions may have been her wondering why I would do such a thing as to send her to the dentist, but I think most of them were simply driven by her basic and innate curiosity. In my opinion, curiosity is the foundation of a business analyst. This curiosity is the driver towards discovering root cause within a project and ultimately providing that “what is the problem we are trying to solve”…the real ‘a-ha’ moment. I have been on projects where, as a result of the “whys”, it was discovered that a technical solution wasn’t even needed and that a change in the business process, communication method or organizational structure would better solve the problem.
3. A constructive Lack of Inhibitions can go a long way…not being afraid to ask questions and not being reticent about not knowing the answers – after answering the litany of “why” questions thrown at me I came to realize that she was very courageous to even ask these questions. She wasn’t afraid that her questions may change my perception of her and she wasn’t afraid to challenge her father or the situation. Having the courage to ask “dumb” questions (even after being told there are no dumb questions) drives the conversation forward. It also encourages others to ask “dumb” questions because then, the underlying foundation for “if he can ask that then I can ask this” leads to better discovery and understanding.
4. Celebrate a Milestone - after her appointment what is a father to do? You guessed it...take her to get ice cream. Am I going to win father of the year? Probably not, but I wanted her to celebrate her first dentist appointment and her conquering something that was unknown and, possibly, scary with a positive “end note”. Participating in a requirement(s) sessions can be an unknown adventure that is both challenging and rewarding. Recognizing the successful completion of requirements for a project is a big deal and, as a business analyst, you should bring to light the major accomplishment (milestone) that it is. Do you need balloons and catered hors d’oeuvres? No, but explaining how the completion of this milestone will foundationally impact the rest of the project goes a long way.
I didn’t expect an innocent visit to the dentist office with my youngest daughter could correlate so closely with my daily challenges as a business analyst and provide me such insight into my profession, yet I remain grateful for the education and perspective I gained. I wonder what I shall gain in the years to come from similar experiences? I’m hoping I find such introspection and edification when the time comes for her to venture into orthodontia for braces.
Randall Logan is the President of PushPull, LLC (www.pushpulltech.com) a management consulting firm in Indianapolis. Randy has over 18yrs experience as a business analyst, project management, process analyst and consulting within the retail, manufacturing, finance, high-tech industries and can be reached at firstname.lastname@example.org
Stakeholder Requirement: Clarified
This is in continuation of my earlier post on Business Requirement. If you have not read that post, I recommend you take a few minutes to study that first before continuing with this post.
In this post, let's discuss Stakeholder Requirement. Some people refer to this as User Requirement, but BABOK's nomenclature is Stakeholder Requirement. Understandably so, because a User (i.e. End User of the solution) is just one type of a Stakeholder. Other Stakeholders, not necessarily Users of the solution, may also have needs that they need satisfied by the solution.
Stakeholder Requirement describes how a given stakeholder would like to interact with the solution, in the context of a business requirement.
Let's observe a few points from the above definition of a Stakeholder Requirement:
1. We already know that Business Requirements must not include the solution. We have discussed this in my previous post. But while defining Stakeholder Requirements, the solution approach must be selected. How else would the stakeholders describe how they would like to interact with the solution?
2. If the solution approach changes, the Stakeholder Requirements also change (but the Business Requirements do not change)
3. In the hierarchy of Requirements, Business Requirements are at the top, immediately followed by Stakeholder Requirements. Every Business Requirement gets decomposed into its constituent Stakeholder Requirements. Stated the other way, one or more Stakeholder Requirements trace into one Business Requirement.
4. Stakeholder Requirements are not at a level of detail for the implementation team to design and develop the solution.
Let’s take an example to understand this better. In my previous post, we had discussed the example of an Insurance Company whose Business Requirement was Ability To Collect Premium Remotely. In order to meet this Business Requirement, there are several solutions possible:
- First obvious solution: enable internet and mobile payment
- Enable direct debit from the customer’s bank account
- Partner with one or more banks and enable the banks to collect the premium
- Authorize the agent to collect premium on behalf of the insurance company. The agent may then provide door collection service
- Establish several satellite premium collection centers
Suppose we select the internet solution, i.e. the insurance company builds a website where customers make premium payments. The following would be some of the Stakeholder Requirements:
Customer: Ability for a Customer to view a list of all policies where premium is due
Customer: Ability for a Customer to make a payment for policy where premium is due
Admin: Ability for the Admin to update the list of policies where premium is due for all customers
Stakeholder Requirements form the basis for defining Solution Requirements. One might ask why bother defining Stakeholder Requirements at all, if it is not useful for the implementation team to design the solution. The reason is simple: A top down structured approach will ensure that the requirements coverage is close to 100%, and the probability of missing out on requirements is very low. Besides this, this approach helps minimize scope creep. I will write more about this in subsequent blogs.
"It should be black in color"
Yes, yes...you are right. This is an elephant.
Well, no. This post is not about the elephant. The elephant is used only for symbolism.
And you are right...there are a lot of other similar posts out there. This is my take on this topic. It is different from others.
So, what does the elephant stand for? Think of a client who is getting killed by that one persistent business challenge. For this client, the business challenge seems "mammoth". And so does the solution to this business challenge - it is mammoth.
I am a Business Analyst working for a company that produces a product - doesn't matter what the product is for the purpose of this blog post. It could be a robot, a software application, a piece of furniture - well, absolutely anything.
It so happens that the client has chosen to purchase my company's product, because their due diligence has indicated that our product is a good solution to their "mammoth" problem.
As a BA, I am working with the client to understand what they "want" from the product. My conversation with the client flows as below:
Client: We have done our due diligence, and I know that your product is black in color. Right? We want one of the features of the solution as "black in color"
Me: Reflecting for a second. Sure, Sure... not a problem. It can be done.
Client: Good. Also, it needs to have rough skin. It must have four legs.
Me: Again, reflecting for a second. Not a problem at all. What else do you want?
Client: It needs to be able to carry cargo and passengers
Me: Sounds good! Not an issue.
Client: We cannot spend a lot on its maintenance. It must be herbivorous.
Me: Reflecting for a second again. Oh yes...true. Not a problem. Will be done.
Client: Oh, I almost forgot. It must have long trunk
Me: Stumped. Oh! You want a trunk? Can you manage without the trunk?
Client: Appears flustered by that question. No, No, No...absolutely not. Trunk is extremely important. Very. It must have a trunk
Me: Trying to salvage the situation. Alright! I will have it done. Anything else Sir?
Client: No, that will be all.
Me: Thanks much Sir. Could you sign off please? Right here on the dotted line.
I then return to my office with the signed off specs. I transition the requirements to the PM. The PM is not too worried. He thinks that the trunk is the only missing piece. He appears confident to deliver the customized solution in about 10 weeks.
I get a call in 6 weeks. The PM is super excited to show me the solution.
When the PM demo's the solution to me, I am super thrilled myself. I am ecstatic. I tell the PM that I will put in a glowing recommendation for her, and that I will personally deliver the product to the client.
So, here I am on my way to the client.
(Image copyright belongs to the owner)
Once at the client location, I demo the product with much excitement. To my dismay, the client does not share the same excitement. In fact, the client has a shocked expression on his face.
Client: What is this? This is not what I wanted.
Me: Confused. Referring to the requirement secs. What do you mean? This is exactly per the specs.
Client: Now getting agitated. I don't care what the specs say. This is not what I wanted.
Me: Trying to placate the client. Sir, I truly don't understand. You asked for four legs. There are four legs. You wanted herbivorous. I personally tested it, this is herbivorous. You wanted it carry cargo and passengers. Again, I personally rode on this thing. It is quite robust. You wanted it black. As you can see, it is black. You wanted one trunk. There is the trunk.
Client: Now getting progressively more agitated.
Me: Desperately trying not to die. Sir, my company takes pride in customer satisfaction. I for one believe in nothing less than customer delight. I have made sure to offer you something as added value that you did not even ask for. Sir, my product gives you milk. You have one more revenue stream Sir!
Client: Bordering furious. Get out of my office!
What is it that I did, or did not do, that got me into such a fiasco? Let's review:
- You see, I did not do my job properly. Scroll up and review what my focus was while the client gave me his requirements. Did you catch it? Yes, that's it...that's what I am talking about. I was ONLY focused on reflecting whether my product already offered what the client was asking for. That doesn't seem like a right approach, does it?
- Furthermore, I did not ever focus on WHY the client wanted whatever he was asking for. As a Business Analyst, my job is to first understand the WHY, and only then the WHAT. When the client asked for the trunk, I instantly realized that my product didn't offer the trunk out of the box. Instead of understanding why the trunk was required, what business purpose does the trunk serve, how it integrates with the rest of the solution, I was only focused on getting the client to relax the trunk requirement.
- "Why" seems to be such a natural question to ask, isn't it? Why do you need the trunk? Why is it such a mandatory requirement? Even so, I did not venture to ask that simple question. How come? Here is the tricky part...if I do ask why, and then realize that my company's product does not meet the client's needs, I would have put myself in a precarious position. I can neither tell the client that my product will not help them (and risk losing the sale), nor can I tell that to my company. Instead, I do what I did...take the easy way out.
As a BA, one should never forget that the most important question to ask is WHY. Understand the business first before getting to the business requirements.
Business Requirement: Clarified
"Business Requirement" is a maligned phrase. Different people have different interpretations for what it means. The worst interpretation that I have come across is, “hey, if the requirement comes from a business stakeholder, then it is a business requirement”. Requirement from business is NOT business requirement. For God's sake, every requirement comes from a stakeholder, otherwise it is not a requirement.
In this blog, I wish to clarify what exactly is a business requirement. I base this entirely on the best practice definitions documented in the BABOK v2 (and v3…truth rarely changes!)
Let’s take a short case:
Assume there is an insurance company that is dealing with a sticky business problem: they have a significant proportion of the policies lapsing by the first anniversary. In other words, the customers who buy an insurance policy today do not renew it the following year and, instead, let the policy lapse. Upon performing root cause analysis, the insurance company determines that the customers do not care to renew their policy because they don’t like to travel all the way to the branch office to pay the premium in order to renew their policy. In fact, they find commuting to the branch office so troublesome that they find it acceptable to let their policy lapse.
Now, what does this insurance company need to deal with the policy lapsing problem?
The insurance company requires an Ability To Collect Premium Remotely. This is a business requirement.
According to the BABOK, a business requirement is simply a statement of goal, objective or outcome of why a change is initiated. (Please see my P.S. at the end of this article)
Let’s take a closer look at the above business requirement:
- Business Requirement exists in the Problem Domain. It captures the need of the business in order to eliminate a problem (actually the symptom). If the insurance company develops the ability to collect premium remotely, then, according to the root cause analysis, more customers will be willing to renew their policies, and consequently the lapse rate will decline.
- Business Requirement MUST NOT capture how it will be met, i.e. the statement of business requirement must not include the solution. This is important. Very important. Well, why is this so? There are a couple of reasons:
- First: Business requirements are developed during Enterprise Analysis (BABOK v2) or Strategy Analysis (v3). To be more specific, they are developed after assessing current state of the organization. At this point in time, no one even know what the solution is because it is not yet identified. Hence the question of including the solution in the statement of business requirement does not even arise.
- Second: there always are multiple potential solutions that can be employed to meet a business requirement. If the statement of business requirement includes a solution, one would tie the organization to the said solution without considering any of the other solutions. In the above insurance company example, there are several solutions possible:
- First obvious solution: enable internet and mobile payment
- Enable direct debit from the customer’s bank account
- Partner with one or more banks and enable the banks to collect the premium
- Authorize the agent to collect premium on behalf of the insurance company. The agent may then provide door collection service
- Establish several satellite premium collection centres
As you can see, any one or more of the above solutions will provide the remote premium collection ability to the insurance company. Thus, it is not prudent to include the solution in the statement of business requirement.
Most people whose role/designation is Business Analyst operate in the IT space. They define the requirements for an IT solution. More often than not, these BAs do not get to define the business requirements because they mostly never participate in Strategy Analysis projects. However, every BA participating in defining the User and Solution requirements MUST begin by understanding the Business Requirements.
More on this in my subsequent blogs...but for now, I will look forward to your comments!
BABOK is probably confusing for a first time reader (even if this first time reader is a seasoned BA). The BABOK makes a confusing statement - it says business requirements are high level statements of goals. This seems incorrect because a goal and requirement are clearly two different things. Here is how I reconcile various terms:
- First comes Business Strategy
- Business Goals are defined from Business Strategy
- Business Objectives are SMARTly decomposed from Business Goals
- Business Requirements are high level statements of goals (not Business Goals) in order to eliminate a Problem that is preventing the org from meeting its Objectives, without including any indication of the Solution in its statement
- Stakeholder Requirements (or User Requirements) are needs of Stakeholders from the selected Solution, in the context of a Business Requirement
- Solution Requirements define the behavior of and constraints imposed on the Solution in order to deliver the Stakeholder Requirements
The most important question for a Business Analyst
Years ago, I was consulting as a Principal Business Analyst for the second largest company in the world in the money transfer business. One fine morning, I was engrossed in my work when my business stakeholder, (let's call him Tom) arrived at my desk.
Tom: Praveen, I have a change request for you. Well, this is a new business requirement.
Me: Oh...a new business requirement! Okay. Sure..let's hear it.
Tom: You know the search screen that we have (see below). I want to change it.
Tom: Essentially, I want you to remove all the search criteria fields, and replace them with just two fields...one, a drop down and the other a text field. The drop down will have the same values as the current search criteria. The Agent (i.e. the User) should first select the search criterion from the drop down, and then enter the search value in the text field.
Me: So, the new screen should look like this, ha?
Now, here is a question for you. Pause reading this article for a minute and ponder over what you would do at this point if you were me. Here are some options:
- Update the Search Transaction use case to reflect the change and pass it over to the design team for implementation
- Ask Tom to meet the PM and follow the change control process
- This seems like such a simple change...there is no change to the actual search function, just some UI modification...so circumvent the change control process and just get it done
- Perform a detailed impact analysis and figure out all other functionality that might be impacted because of this change.
- None of the above
What would you do? Which option would you opt for?
Sounds like option 4 would be the most logical path to take.
However, if you chose option 5, you would be right. I didn't choose any of options 1 thru 4 either.
What I did was to ask the most important question that a BA must ask -WHY.
Me: Tom, this is a simple change no doubt. If you could humor me for a couple of minutes, I would really like to know why you need this change? What is happening in the business that triggered you to bring this change request?
Tom: Here is the issue Praveen. You see, when a customer intends to make a money transfer transaction, she first logs on to our website. She then creates a Send Transaction where she enters all the details, i.e. the sender details, the receiver details, the amount of money to be transferred, etc. Once she enters all these details, she saves the transaction.
Me: Okay...got it!
Tom: Then, she takes the actual cash and heads to one of our Agent location. The Agent has access to a money transfer terminal. The Agent asks for her name to pull up the saved transaction on his terminal. The customer states her first name. Now the Agent types in her name in the Last Name field. The transaction is not found. The Agent asks her name again, makes a mistake...and can't find the transaction. The customer is irritated, and she goes out straight to our competitor.
Me: Oh vow!
Tom: That is why I want this change. I want to make sure that the Agent actually asks the customer whether she is stating is her first name, last name or something else. That is why the drop down field. I want to make sure that the Agent is able to pull up the transaction in the first attempt.
Now, my dear reader...think about this real business problem and then look at the "business requirement" that Tom has brought to me. What can you observe?
Did you get it? Exactly...you got it!
One, Tom has actually brought you his perceived solution and has disguised it as a business requirement.
Two, the solution that Tom has brought will definitely NOT solve his business problem. How can having a drop down box eliminate the possibility of making mistakes on the search screen?
Having now understood the real business problem, you can think of several possible solutions:
- When the customer saves the transaction, let's create a unique ID. Instead of searching for the transaction using name or other criteria, searching using the unique ID is much more robust
- Create an intelligent search function, where there is no need for any search criteria label...enter anything - name, SSN or anything else. Make the search function so robust that it searches all saved transactions and pulls up all transactions closely matching the search value and displays the search results sorted by relevance
Think about what would have happened had I not asked that 'WHY' question! I would have ended up implementing what Tom wants, and not what Tom needs. After the new search function is released to production, Tom would have very soon realized that the solution is not working at all and his problem still persists. Who Tom would blame then is anybody's guess.
By the way, in my 15+ year career as a BA, I have noticed several BAs not asking this WHY question. This is why I suspect these BAs become infamous in their team as "just postmen" who add no real value to the project.
I cannot really overemphasize the importance of asking WHY for a BA. A good BA will always understand the true underlying business problem and solve that problem. A good BA will never take any statement from a stakeholder at face value and treat it as a requirement. Remember the 'A' of BA!
P.S. It would be interesting for you to learn that solution #1 above could not be implemented because a competing organization had patented that process! The patent prevented my client from creating any identifier that uniquely identified the transaction. My client therefore had to use one or more pre-existing identifiers to identify the transaction.
Business Analyst - The ONE – Part 4
We saw about the problems and the ways of defining a solution to those problems in the last article. Also, I had mentioned that when a problem arises, there is a need for the business to resolve that problem. So, what would be business needs? It again depends on the problems which they face. By definition, Needs are desires of the project customer that focuses on a business problem; its fulfillment is strategic to organization goals. In IT world, it is to identify and define why a change to an organizational system or capabilities is required.
Determining specific business needs is the main objective which as a business analyst you might need to clarify and understand it completely in order to be most effective, as the solution is driven by those needs and your project will also be evaluated based on those.
Most of the business needs arise due to the common issues such as loss of revenue, customer complaints or a direction towards which the entire organization need to move, like regulatory bodies defining a common rule which need to be followed by all the organizations. In our previous example on the problem faced by the hotel business on customer smoking, the main business need was to eradicate this particular problem which was resulting in bad customer experience and due to which there was a revenue loss. So, without someone acting as an analyst, the business wouldn’t have a compass or a map to guide them in resolving such issues.
As an analyst, here you are in the role of defining the needs from the business point of view (remember the initial writing, where I mentioned the different type of business analysts, this role is more from the person who is working from business side to provide the details to the technology or provide solutions by themselves), you are expected to define the business needs considering the following points
1. How then different stake holders like end users, front-line workers, management, vendors or any other stake holders / different business units define the perceived problem?
2. The areas which are affected by the problem, like client retention, gross/net revenue or development budgets etc.
3. Feasibility, drawbacks and benefits of suggested solutions to eradicate the mentioned problem, like in terms of manpower, revenue, capacity.
When you say you need to define a business need, you can represent that need in terms of multiple ways. When there is a technological improvement required based on your business need and when you are trying to define the business need for technology to understand, don’t define in such a way that what you want system to do for your need, define what your expectation from the need for your business improvement. As when it is defined in terms of what business need is that time, the change in the business based on that need is also identified. So, think and specify your needs in terms of new, value-delivering processes and opportunities like how you want to work in the future, the process steps, information needs and process logic. Then you'll have systems that align exactly with your needs.
The business need is not typically a stand-alone deliverable or document. Instead, the business need is a very high-level business requirement that should be included in the business requirements document or business case for your proposed project.
In traditional method of defining a need, an analyst will define the need in terms of his requirements, corresponding document known as Business Requirements Document and all the details of the changes that are expected shall be incorporated in to one single document. In modern trend, everyone being agile in their process, the needs are split in to individual stories and each story explaining a specific requirement for that need. Since the story is defined by the end user, it is again termed as a User story and a model user story will look like below
As a hotel manager, I need to have smoking zones in my hotel so that I can have a better customer experience and increase in revenue because of that.
To define the business need and understand the desired outcome, try brainstorming with end users and personnel, analyzing the current ways the company does business to identify weaknesses, interviewing subject matter experts, and holding focus groups for stakeholders and users. Analyze every aspect of the business, even those you aren’t confident are part of the issue.
So, what’s next!!! Yes, now we have “opportunities” to explore further 🙂
Things to know before you start your BA career
Now when I am already a successful BA since many years, I would like to share few moments with everyone.
During my first months as a business analyst, life was filled with a sort of inner turmoil. Even though I had books on how to write requirements documents, had received individual mentoring on putting together use cases, and had a trusted set of templates to follow, there was something uncertain about how the business analysis process would actually unfold.
I found myself making a lot of mistaken assumptions about what to expect, having those assumptions prove to be unfounded, and then needing to find ways to adjust and course correct. Looking back, there is nothing unexpected about my experiences, except that they were unexpected to me at the time.
Knowing that many of you are just getting started, today I am sharing 4 of the things I wish someone had told me when I was just starting out in my business analysis career.
Need to set expectations early and often, and then again and again and again…
As a business analyst, it’s not uncommon to receive too many assignments, tasks that are outside your bailiwick, or unreasonable deadlines. I was surprised to find myself constantly explaining what I was doing, why it was taking so long, and what could be expected of me over the coming weeks, even though I didn’t always know what the next week would look like!
I also found that deadlines would seem reasonable but became overly optimistic when I didn’t hear back from stakeholders in a timely manner, couldn’t get time on the calendar with a critical stakeholder for weeks at a time, or encountered unexpected issues.
I learned to continually clarify my role, communicate about what would be done when, and seek feedback to be sure I was meeting expectations.
Getting information could be a little painful
Early on in my career, I naively expected unlimited access to stakeholders and their unhindered involvement in and passion about my projects.
The reality was much different. My stakeholders had multiple projects, conflicting priorities, and too much to do. Even when my project was important to them, it could still be difficult to get the information I needed in a timely manner.
Over my career, I learned to be a bit of a squeaky wheel – a very polite, diplomatic, and conscientious one – but squeaky nonetheless. My projects started to move more smoothly and I met my deadlines with less angst.
Although being the requirements author, you aren’t the requirements owner.
I love to write and I love to write requirements. But I could get so caught up in writing and documenting and modeling that I would take on more ownership than was prudent. This would lead to a lack of buy-in from critical stakeholders, which could translate to unexpected changes late in the project.
The reality is that we absolutely need stakeholders to take ownership of the content going into the requirements document, even as we author that document on their behalf. And yes, they are likely to resist reading, reviewing, and providing feedback on requirements.
I learned that providing early, incomplete drafts that were clearly imperfect would help stakeholders see that they could add a lot of information and clarity into the requirements. I also learned to be very specific about the status of any given deliverable when sending it out, and equally specific about what I was asking of my stakeholders of this document at this time.
Dealing with issues professionally would take a new kind of finesse
I’ve always been a proactive person and a bit of a whistle-blower. When a new issue surfaced, I would signal the alarm, rally the troops, and facilitate a problem solving meeting.
However, discovering requirements is a gradual process of gaining clarity and minimizing ambiguity. At a certain point in time, every requirement was once an issue. Business analysis surfaces so many issues that you can’t possibly resolve all of them immediately.
With experience, I learned to blow the whistle more softly, keeping everyone informed about what was surfacing, but not unnecessarily alarmed. To keep the requirements process moving forward, I also learned to take ownership of the issues that surfaced inside of the requirements, and make more decisions about how to resolve issues and which options to choose or recommend.
Now that you know what to expect
Now that you know what to expect, perhaps you won’t be as caught off-guard as I was during your first days as a business analyst!
Happy Analysis !!!
job search - Google News
International Job Search - Penn Law (press release)
International Job Search
Penn Law (press release)
International Law is always of popular interest among students, which is not surprising as it offers some of the most exciting and fulfilling opportunities in law. However it covers a very wide range of practices - from working in a domestic law firm ...
Five Job-Search Tactics That Work -- And Five That Don't - Forbes
Five Job-Search Tactics That Work -- And Five That Don't
One of the biggest problems for job-seekers is that the standard recruiting process is so broken, you can't easily tell whether your job-hunting strategy is working or not. When you fill out countless online job applications and hear nothing back from ...
Six months and no offers could mean job search needs a break - Minneapolis Star Tribune
Minneapolis Star Tribune
Six months and no offers could mean job search needs a break
Minneapolis Star Tribune
Odds are that you're quite preoccupied with your job search. The first step that I strongly recommend is giving yourself a break. Even one day off will give you a boost. Take a day with an upbeat friend or a spouse/partner doing some cheap, fun, local ...
Navigate Your Way to Job Search Success with a Free Lecture Series - TAPinto.net
Navigate Your Way to Job Search Success with a Free Lecture Series
Somerville, NJ – Today's ever-changing work climate requires the job seeker to constantly adjust course and keep abreast of new trends. To meet this challenge, the Professional Service Group of Central New Jersey (PSGCNJ) offers a free lecture series ...
The One Tiny Change That Could Open Up All The Doors In Your Job Search - Forbes
The One Tiny Change That Could Open Up All The Doors In Your Job Search
Ever since I've started working at The Muse, I've gotten cornered by people at social gatherings who whisper in my ear, “Hey, I'm looking for a job, I heard you can help.” I typically respond by pulling the person into a back alley, opening up my ...
8 minor job search decisions you can stop overthinking - CNBC
8 minor job search decisions you can stop overthinking
Whether you're unemployed or just keeping an eye out for new opportunities, there are tons of tiny decisions that you have to make during a job search. But, you should be concentrating your efforts on polishing that resume, perfecting your interview ...
4 Simple Steps To Refresh Your Job Search for Spring - Forbes
4 Simple Steps To Refresh Your Job Search for Spring
Spring feels like it's finally arrived — but has your next job offer? If you've been slinging resumes for the past few months with no success, take these simple steps now to bring some of that spring cleaning spirit to refresh your job search. If you ...
Working Strategies: Recovering from self-inflicted job search wounds - TwinCities.com-Pioneer Press
Working Strategies: Recovering from self-inflicted job search wounds
We've all done it, right? Said something regrettable to a recruiter, perhaps, or driven to the wrong site for an interview? These are just two of the many self-inflicted job search wounds I've heard from my clients — or perpetrated myself ...
Unemployed in Norristown? Job Search On Patch - Patch.com
Unemployed in Norristown? Job Search On Patch
The American workforce added a disappointing 98,000 jobs in March, while the unemployment rate fell to 4.5 percent, according to Friday's report from the Bureau of Labor Statistics. Observers had expected at least double the jobs growth ...
Job search 'pretty rough' - The North Bay Nugget
The North Bay Nugget
Job search 'pretty rough'
The North Bay Nugget
“The whole North seems to have a very slow season,” Sean Evans said Thursday as he filled out an application at the Job Fair at the Davedi Club, one of a number of Workforce Week 2017 events. “It's ending right about now, but the winter was tough ...
Systems Analyst Jobs
Listed by State – Updated Daily
Powered by FirstRSS Plugin