In very basic terms, business analysis could be said to be the application of a range of disciplines, to determine business needs and develop solutions to business problems. Of course, in practice this short description becomes entirely inadequate, a far more exhaustive explanation is required to explain exactly what business analysis actually is.
Business Analysis is a term which refers to the process of firstly identifying the needs of the business and then developing and implementing the solutions to meet them. Business analysis techniques are applied to develop an appropriate plan and then put it in to action. Business Analysts are an important asset to every business, they apply their skills to take the big picture and break it into smaller parts, making it easier to ensure that company resources are being utilized in the most efficient manner.
Business analysis always focuses upon goals, but in a bi-directional fashion. Business analysis can be implemented to both set goals, and to achieve them. These goals will cover strategic business practices encompassing IT, business processes, corporate policies, structure and trading strategies across the entire enterprise.
The term business analysis is a broad term given to the process of analyzing and influencing three distinctly different aspects of the business, which combined, effect the enterprise at every level, these are:
Depending upon the market sector the enterprise sits within, different business analysis techniques will be applied. Different techniques may also be applied at project level. Some of the most common of these techniques are:
These are just a handful of the mainstream techniques which make up the toolset of the modern business analyst. These are very succinct descriptions, each of these techniques is worthy of several pages of description in their own right.
Every time that business analysis techniques are applied, there is a natural three phase progression, which can be explained thus:
Business analysis is important for many reasons, although the main one should be quite apparent; business analysis allows a company to take carefully iterated steps towards achieving greater profitability by working
Every enterprise is the sum of its stock value, working capital, tangible assets, customers, staff and goodwill. By employing modern business analysis techniques, the value of each of these core aspects. Hopefully this has answered the question of what is business analysis.
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.
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.
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 them everything just fades away or collapses. Identify your core users then profile them to build meaningful interfaces and processes targeted directly at them. Target your communications and marketing strategies for your vision and product to them very specifically. Knowing how to turn the heads of your core users and get them to support your vision is critical to your success. Once the core users are on board all the other types of users will fall into place. Build a fan base. Even an accounting application can have a fan base. Fans support you and give you new ideas to build your vision. Treat your fans well and they will support you through thick and thin.
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!
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 were called mainframes. Mammoth monsters that would manage large amounts of data, electricity and generate a lot of heat. They required a forklift to move and had to be water cooled.
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.
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 better shared understanding of the project.
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.
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 Say Leader
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.
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?
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 requiredStepping 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.
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’.
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.
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!
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:ELEMENT NOTATION DESCRIPTION Decision The act of determining an output from a number of inputs, using decision logic which may reference one or more business knowledge models. BusinessKnowledge Model A function encapsulating business knowledge, in the form of business rules, decision table or analytic model. Some of the tool may not support this element. In such case the decision logic is directly linked to the Decision rather than the business knowledge model. KnowledgeSource The authority for a business knowledge model or decision. Input Data Information used as an input by one or more decisions. It also denotes the parameters of a Business Knowledge Model. Information Requirement Information – input data or decision output – required for a decision. Knowledge Requirement The invocation of a business knowledge model. Authority Requirement Showing the knowledge source of an element or the dependency of a knowledge source on input data. Decision Table
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.Advantages
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
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
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.
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 frequencyRequirements 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.Conclusion
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.