Skip to main content

Tag: Business Analysis

Why Everyone Needs a Business Analyst on the Project

I’m a Project Manager and a consultant.  I’ve never been a Business Analyst.  I’ve been an Application Developer, but never a Business Analyst. 

I’ve helped the Business Analyst do their job on many of my projects and the BA is usually the one that I work most closely with on the projects that I manage.  But I’ve never had sole responsibility for the business analyst function on a project.  And I truly believe that my project management success rate can be directly tied to working with some great, experienced Business Analysts on some of my most technical and complex projects.  There is no substitute, in my opinion.  I will sing their praises from the rooftops.

Why does everyone need a Business Analyst on their project?  That may be a bit of an overstatement…there are those smaller and less complex projects where a Project Manager or Business aAnalyst can likely cover both roles.  But for longer term, higher profile and more technically complex projects, I strongly suggest that both roles are absolutely necessary.  I am going to present my own five-point argument here as to why that is the case.  I welcome your thoughts and input and discussion to either support or refute this concept. 

Here are my five reasons why every (most?) projects – at least complex, technical ones –  need a Business Analyst:

1.     The Project Manager needs to focus on the project management tasks. 

There are enough administrative tasks on most projects to justify a full-time Project Manager, in my opinion.  This is especially true for longer, more complex technical projects.  In recent years, I can’t imagine not having a Business Analyst assigned to most of the projects I’ve run as they have often tended to be at least 6-12 months long and worth around $1 million with fairly complex technical solutions, interfaces, and implementations.  Asking a Project Manager to cover both roles is asking too much because managing a project like that – depending on the customer’s needs and complexity of the project – can be a full-time job.

2.     The Tech Lead needs a good liaison heading into design work on the project. 

On most technical projects of any degree of complexity, the project can benefit greatly from having that good liaison between the administrative and customer side of the project and the technical development side.  Having the BA in place to help translate those business requirements into functional requirements with and for the Tech Lead on the project is of tremendous value and helps keep that planning portion of the project under control in terms of time and dollars.  It can often definitely be money well spent on the Business Analyst position.  If it isn’t spent on that position on complex, technical projects, then it likely will be spent on a longer planning and design portion of the project.

3.     The Customer needs a technical interface to create complete, detailed requirements.  

Customers rarely come to the project table with detailed requirements and if they think that’s what they have then those requirements need to be questioned heavily. To get to usable, detailed, complete requirements is no small effort and the Business Analyst provides the best means of getting the project to the point of that detailed requirements definition.  On most complex tech projects, it’s going to be impossible for the Project Manager to be the sole facilitator of that process.

4.     A Business Analyst provides key assistance with user acceptance testing (UAT). 

User acceptance testing is critical to the project’s success.  So much so that the UAT signoff is almost like a signoff on the entire project.  But so many UATs can and do go poorly as many project clients lack the time, experience, and expertise to dutifully prepare for and conduct proper user acceptance testing.  While the delivery organization can’t do the testing for them, a good,  experienced BA – sometimes along with the Tech Lead’s and/or Project Manager’s help – can show them how to prepare properly and conduct UAT by assisting the customer with test cases and test scenarios.  This way both sides can be certain that the solution has been fully and properly tested prior to signoff and that the end solution is nearly certain of meeting the customer’s end user needs upon rollout.

5.     Business analysts provide critical oversight at project implementation time.  

Is the project complete?  Is it really ready for roll-out?  Probably, but have you gone through a project checklist to ensure that is the case?  Have you reviewed the project schedule to ensure all tasks are complete, that all sign-offs and approvals have been obtained along the way, and all documentation is there to prove it?  The Business Analyst – if you have one – has been involved in many of the key deliverables and heavily involved in requirements, functional design, reviews, user acceptance testing, and other testing as the solution moves toward implementation.  When the time does come for go-live, the Business Analyst can likely be the best interface with the project client – working closely with the Project Manager and the tech team to ensure the solution is rolled out smoothly to the customer and end users, that training needs have been identified and addressed and that the proper handoff to support has been achieved.

Summary / call for input

I’m a better Project Manager with a Business Analyst on board for the project.  Likewise, my projects are better equipped for success when I’m not splitting myself too thin as both the Project Manager and Business Analyst.  I realize that it is a luxury to accommodate both roles on the project as it can be a matter of budget, complexity and customer agreement.  Both roles need to be funded.  I still stand by the notion that every project is better off if you can have both roles filled separately, even if the Business Analyst or Project Manager role is very limited in terms of hours, dollars, and involvement.  Better to have a few hours here and there as needed as opposed to none.  So, if you can’t price both in full time, then price one in part time and strategically use those hours wisely where they are most needed – like early planning and design and then again around user acceptance testing where business analyst involvement can really help that often customer-challenged phase of the project go much more smoothly.

Readers – what are your thoughts?  How necessary do you see both roles as being on the projects in your organization?  How often does on or the other role cover both position on a project?  Please share and discuss.

A Detailed WBS – The BA’s Best Friend

As a Business Analyst (BA) how often have you been asked to provide an estimate for a requirements elicitation and analysis effort and, upon providing it, had your estimate cut back by management in a seemingly arbitrary fashion?

I recently attended a conference for Project Managers (PMs) and BAs where this issue was brought up during a requirements planning techniques seminar. I heard stories from several of the BAs in attendance that their management would look at the estimated time and resource plans and summarily cut them by 30% while keeping the same project scope. Other managers would simply say, “that’s too much time, figure out how to do it faster.” The question raised in the seminar was “how do you deal with these situations or prevent them from happening?”

The best approach I have found is to be armed with as much objective and quantifiable information as possible to support your estimate – in other words – a detailed Work Breakdown Structure (WBS).

When developing estimates for requirements elicitation and analysis, many PMs and BAs will lay out the tasks to be executed and even include some resource assignments and dependencies, in a high-level WBS. More often than not, however, they are not very detailed and, subsequently, not very accurate. Below is an example of a basic WBS and Level of Effort estimate for a seemingly simple project involving elicitation of requirements for a system, assuming the project requires interviews with 2 groups of users and an analysis of associated existing process and system documentation.

wren1

Although the estimate seems to include all the necessary tasks, durations and dependencies, if we look at it through the lens of a Business Analyst who might be responsible for doing the actual work, we will see that the effort required becomes significantly larger.

wren2

When we factor in standard information gathering, interview preparation, requirements analysis, review and revision tasks along with their associated time frames, we see that our simple requirements analysis effort takes significantly longer than initially planned to complete. The development of this more comprehensive listing of tasks is based on a variety of inputs including:

  • Analyst’s experience on past projects and associated activities
  • Similar project comparisons
  • Exhaustive brainstorming and analysis of all tasks required to complete the deliverables

Having a detailed WBS allows the BA to call out all the activities required and helps ensure all project members are aware of required time and resources.

Related Article: The Agile BA – Moving Beyond the Backlog

That said, just because a BA can show why they require certain requests, a certain timeline, and set of resources to complete the analysis effort, does not guarantee that those requests will be granted. There may be existing time, resource or budget constraints with which the project and requirements analysis effort must comply. In those instances, a detailed WBS can be used to evaluate objectively which activities and scope items are essential and which can possibly be omitted. This will hopefully result in an adjustment of scope, schedule or deliverable expectations.

Example: If I can only have two (2) days it means I can only get requirements from one (1) of the two groups.

If adjustments to expectations are not made, at least this exercise should result in a specific identification of risks to the requirements effort so that steps can be taken to mitigate the probability or impact of their occurrence.

Example: If I can only have three (3) days it means I can’t do a thorough document analysis, so the interviewees need to make sure they cover all possible processes and requirements.

By developing a detailed WBS for any analysis effort, a BA can help ensure that deliverable expectations are understood and agreed to by all project participants and that adequate time and resources are available to complete the process effectively.

BABOK Notes

The process of estimating tasks and durations for requirements elicitation described above are covered in detail in the Business Analysis Planning section of the Business Analysis Body of Knowledge (BABOK) published by the International Institute of Business Analysis (IIBA). A link to the BABOK on the IIBA website is provided below:
http://www.iiba.org/babok-guide.aspx

Cooking Up Business Analysis Success

In 1961, the great Julia Child revolutionized the cooking industry with her book “Mastering the Art of French Cooking”. This book cemented Julia as an expert in French cuisine and launched her career as a gourmet chef.

In 1963, Julia used her new found fame to revolutionize the television industry by creating a weekly half-hour cooking program. Her success paved the way for all of the cooking shows on television today.

So what does this brief history of Julia Child have to do with Business Analysis you may ask? Let me explain. Julia’s book was extremely successful because it provided very clear, simple instructions along with supporting photographs to illustrate the final product. This recipe for success launched Julia Child’s career from relative obscurity to international fame.

To succeed as a Business Analyst, you must strive to deliver consistently clear and unambiguous requirements that are understood by all audiences. The most successful business analysts will also create visuals to support the requirements they write. In this respect, BAs would be very wise to follow the formula that launched the success of Julia’s famous book.

I’ve developed a recipe that business analysts can follow that will ensure they will deliver high-quality requirements that are guaranteed to satisfy the business needs of their customers. The recipe is as follows:

  1. Define the problem 
  2. Define the Scope
  3. Create an Actor – Goal list
  4. Create supporting visuals
  5. Write detailed requirements 

Step 1 – Define the Problem

The very first step in the business analysis process is to define accurately the problem the business needs to solve. It is human nature to rush into a solution. However, a great BA would be wise to keep in mind the famous words of Albert Einstein, who once said “If I had one hour to save the world I would spend 55 minutes defining the problem and 5 minutes solving it.”

Related Article: Know Your Audience – Don’t Let Requirements Get Lost in Translation

In my experience, most people on the project team as well as management, are impatient and want to push forward with implementing a solution as quickly as possible. They fall in love with the solution, not the problem. This mentality significantly increases the risk that the project will deliver a solution that does not fully meet the customers’ expectations. BAs must lead teams to fall in love with the problem, not the solution. So how does a BA slow the team down and concentrate on defining the problem? We need to use a simple template for a well-defined problem statement. The template contains four simple sections.

Ideal – this section allows our customers to define the ideal solution or process. It forces the stakeholders and the project team to define what would be an ideal solution to their problem. The information discovered via this exercise will help determine the actual scope of the project as well as uncover the most important features the customers are expecting. Feel free to use collaborative games or other interesting elicitation techniques to make this a fun exercise for your team.

Reality – this section allows our customers to define the current reality of their situation. Understanding the reality of a customer’s current situation is helpful to understand the most significant pain points in the current process. Empathy mapping is a useful technique for this section since it allows you to understand how users feel and think about the current process.

Consequences – this section is used to define the actual consequences the business may suffer if the problem is not solved. It is critical to define the actual consequences that the current problem is causing. For example, ask your stakeholders if the current problem is causing productivity loss, revenue loss, or is putting the company at a competitive disadvantage. Understanding the actual consequences allows the business to prioritize the project. It also allows the project team to understand how the solution they create will actually impact the business.

Proposal – the proposal section is used to articulate options for solving the problem. Completing this section allows the delivery team the opportunity to provide an initial set of solution options which are feasible. Having your customers and the delivery team have a discussion on potential solution options is extremely important. It ensures both sides are in agreement on the path forward and helps to define further the scope of the project.

Step 2 – Define the Scope

Once the problem is defined via a well-defined Problem Statement the scope of the solution is much easier to lock down. The Scope Statement does not need to be a complicated document that takes a long time to complete. The information provided in the problem statement should allow you to come quickly to an agreement on what is in scope as well as what is out of scope.

Step 3 – Create an Actor – Goal List

Great business analysts are able to understand who is involved in the current process as well as who will be involved in using the new solution. This analysis results in the creation of a list of Actors associated with the current problem. For each Actor identified the business analyst should understand the goal they are trying to achieve. For example, let’s consider a typical web-based application that allows a customer to order products. A realistic Actor – Goal list for this solution would be:

Customer – Search for Product

Customer – View a Specific Item

Customer – Add Item to Basket

Customer – Place Order System – Verify Payment Information

Obviously, this is not a complete list, but you should get the idea. If you write each goal in Verb – Noun format you may simply associate each Actor – Goal combination with a single Use Case or User Story. This exercise allows you to organize the requirements in a way that ensures the most important functions of the stakeholders are accounted for.

Step 4 – Create Supporting Visuals

Using visualization is absolutely critical to convey requirements. Visuals allow for the proper discussion to occur in order to elicit the detailed requirements from your stakeholders. A picture truly is worth a thousand words. Visuals may include mock wireframes, prototypes, process flows, and data flow diagrams. Visually mocking up the solution allows the BA to obtain feedback quickly and discuss the details of the proposed solution prior to developing it. Taking the time to create visuals and discuss them allows the detailed requirements to fall simply out of the discussion. You will be amazed at how easily the requirements become clear when you are discussing a visual with your stakeholders.

Step 5 – Write Detailed Requirements

Once the problem has been well-defined and agreed upon, the scope has been solidified, the actors and their goals have been considered, and the visuals have been discussed, you are ready to put together the detailed requirements. Each requirement should be associated to a single Use Case or User Story, which is directly associated to a single Actor – Goal. This ensures that each requirement is directly involved in satisfying a goal of your customer and will be adding value to the solution. Requirements should be written in Subject-Verb-Object (SVO) format and be clear and unambiguous. The key to clarity in the English language is the relationship between the Subject, Verb, and Object. If a common sentence clearly defines WHO the Subject is, WHAT they will be doing and to whom they are doing it, then the reader should have no problem understanding it.

Following this recipe for requirements elicitation may not launch you into international fame and a lucrative television show. However, it is likely to set you on a path for success in your business analysis career by establishing agreement and trust within the team.

The Business of Process Analysis

As Business Analysts, we’ve probably all had to map processes. But the question is ‘did we succeed in what we set out to do?’

Process analysis and its subsequent mapping are seemingly very rudimentary business analysis skills. It is something that a Business Analyst should be able to handle even at a fairly junior level. When we set out to perform process analysis do we really understand what we are trying to get out of it and are we properly prepared to deal with whatever the result?
Thinking back over my time as an analyst I can recall quite a few times where I would be doing process analysis in a fully prepared state, or so I thought, but in hindsight, I was doing little more than conducting meetings and doing even less with the results.

So why would we do process analysis in the first place? To understand the AS IS state is one obvious reason. Another common response would be that it needs to be done as part of a contractual deliverable. But even in the absence if these most basic reasons there are many other good reasons why we should be doing it.

Let’s Visualize our World

Doing process analysis and mapping out the results allows all stakeholders to see the bigger picture, and not just their part of it. Whether they like what they see or not is irrelevant. What is relevant is the fact that the bigger picture stirs up a lot of discussions which leads to the second reason why we do it.

Solve the Problem

All the talking and discussions that result from a process map gets the creative juices flowing and not only helps stakeholders to rethink those processes where they knew they were not doing too well but, more importantly, help them rethink those processes that they thought they were doing great.

Identify Functional Gaps

Potentially the most dangerous reason why we do process analysis. I say this because you have the very real danger of exposing functional gaps in your supporting systems during the analysis process. Hopefully, there is room to close these gaps but there is also the danger that they cannot be closed within the scope of an existing project. I mention that it is potentially dangerous but not exposing such gaps can be even worse.

Once you know why you want, or need, to do process analysis and you understand how to manage the possible outfall the rest is fairly simple.

Know Your Stakeholders

Getting to know your stakeholders means that you have an understanding of how they interact and where they fit into the bigger organization.

Select Techniques

People, in general, tend to become set in their ways when they are not actively challenged. Business Analysts are no different so reevaluating your approach and techniques is always a good idea. Sure, the way you have done things in the past worked so don’t fix it if it ain’t broke right? Maybe. But every audience is different and the techniques that you will use needs relatable. Remember that the stakeholders will be (should be) active participants in your analysis process and for somebody to be active they need to be engaged. You cannot engage somebody in something they do not relate to. No matter what techniques you decide on you can improve the efficiency by

  • Conducting Research

Research as an analysis technique is often neglected. Doing research to understand the background of what you are trying to achieve is vital and will give you an important head start. One of the key aspects of facilitating a process analysis workshop is the ability to question everything, but the line of questioning should be aligned with fact. Your research will provide you with these facts. Try to be as unobtrusive as possible when researching and stick to the basics. DO NOT be tempted to skim over something during the workshop sessions because you already KNOW it.

  • Being Agile

Select a technique that will allow you to be agile. Things can change quickly during a workshop session, and you do not want to be apologizing for spending lots of time fixing or changing something. While a whiteboard allows you to erase or redo anything, it becomes a bit messy when you are at gate 34, and you need to make a change at gate 2. Messy is a fact of life when it comes to process mapping workshops, but it must be a good messy i.e. controlled chaos. I prefer using post-it notes on flip chart pages. Depending on the process I would stick the flip chart page onto a wall and proceed to draw out the process using the post-it notes. The post-it notes allow me to be very agile while the flip chart pages allow me to expand in any direction. While I tend to stick to the more conservative side, the availability of post-it shapes and colours allows you to be very creative.

anton1
VS

anton2

  • Being Comfortable

Stick to techniques that you are comfortable using. Hopefully, as a Business Analyst, you are comfortable in your position as a facilitator but that only gets you to the point where you need to use a technique or tool. Stakeholders can smell blood in the water, especially hostile ones. If you do decide on a technique or tool that you are not 100% comfortable using, then practice until you are. An analysis workshop is not the time to ‘wing’ it.

The Workshop

This is where the rubber meets the road, where all the preparation you have done pays off. You did prepare, right? Who goes into a meeting or workshop as a facilitator and do not prepare? Well, there is prepare, and then there is PREPARE. I’ve done both, and I can tell you that they are not equal. So some pointers when the time comes to show off your skills.

  • Ensure everything works. If you are using a technique that requires that a large open space, make sure the technique is possible in the actual venue. Keep factors like lighting, ventilation, and accessibility in mind.
  • Engage ALL stakeholders. Make sure that the seating positions are arranged to ensure that everybody has an equal opportunity to participate. Remember that they might not even need a table in front of them and even standing in a semi-circle around a chart could work with a small group. Standup meetings have been proven to be a great way to get people going, and keep them going. It can apply to a workshop too.
  • Question everything, well almost. Not only is it a very effective way of engaging stakeholders, but asking questions also makes them think. You did your research so you have some facts that you could use to raise sensible questions.
  • Focus on the AS IS. While it might be very tempting to show off you prowess as a Business Analyst by highlighting shortfalls in the existing processes, it is much more effective to focus on what they are currently doing. The time to fix it will come soon enough. But don’t squash ideas coming from stakeholders. Save these ideas for consideration during the TO BE process designs.

The workshop is done, and you have walked away with a heap of information. It is time to produce the output, probably in the form of an analysis report containing the AS IS and TO BE states for the processes you have mapped. The output is as, if not more important than the actual workshop. While only a select group attended the workshop, the report will find its way to many who were not part of this initial process.

  • Use a format that all stakeholders can relate to and understand. Most people are familiar with the basic flow diagram and decision gateways, so that is a good starting point.
  • Breakdown big processes into smaller sub-processes for easier reading.
  • If your objective was process improvement, make sure that the proposed TO BE state is something that can be supported, either by the project scope or supporting systems.
  • Make sure to spell out clearly what can be achieved and what cannot. You might want to map out TO BE states in a phased approach when the best possible solution cannot be implemented within the current scope constraint.
  • Highlight changes that will have a significant impact on resources. These impacts could be training or hiring needs.
  • Most importantly, produce the output as soon as possible. Do not be tempted to reprioritize activities just because you have taken careful notes of all the proceedings.

And you are done. There are few things as satisfying as delivering a good quality document to stakeholders that they can understand and agree on. The cherry on top is actually implementing the improved process changes. But all this success is only possible if you used the right techniques and tools, prepared properly and produced quality documentation.

10 Essential Apps for the Business Analyst

Let’s face it, a career in business analysis isn’t one where you’re at your desk from 9-5. It requires you to be out in front of people, having conversations, and collaborating. It requires you to be mobile, both from a physical sense and technological sense. People often laugh at (and maybe get a little annoyed) when others have their faces buried in a phone, but the reality is that most of us have our phones in our pockets at all times. Some of you are reading this on your phone at this very moment.

As I began pondering this world of “always-on” mobile connectivity, it became clear that there has to be greater value in having that phone in your pocket than just simply playing Candy Crush in your free time. In my quest to find value, I have identified 10 apps that can increase your productivity and help you collaborate and engage your stakeholders in a mobile world.

  1. BA Glossary – This app is a great reference for definitions of BA tools, techniques, and terms. It’s helpful when you need to look up a new term quickly or if you simply want to browse and review. It features an intuitive search function that narrows the results as you type which is helpful when you don’t know exactly which word you’re looking for. Its simple layout and multitude of terms makes this app an efficient tool for any BA. Available in the Apple App Store.
  2. MindTools – If you want to take your reference materials to another level, MindTools is right for you. This app features extensive material on many different techniques from strategy tools to communication tools to time management. You’ll have access to over 100 useful tools such as impact analysis, value chain analysis, and emotional intelligence. The app goes far beyond just providing definitions; it provides pages of information on each tool including links to external sources and videos that are relevant to the topic. Available in Google Play and the Apple App Store.
  3. Smartsheet – Ok, this app is more oriented for the project manager role but many business analysts perform both roles to some degree. With Smartsheet, you’ll be able to create project schedules, budgets, feature roadmaps, task lists with Gantt layouts, and more. A nice feature included with the app are templates so that you aren’t starting from scratch (although that is an option). One other great feature is that the app allows you to export and send documents in both Excel and PDF formats. Available in Google Play and the Apple App Store.
  4. SurveyMonkey – Surveying stakeholders is a classic tool for business analysts, but the SurveyMonkey app lets you quickly and easily create custom surveys that have meaning for whatever your topic is. The app lets you add many different question types such as dropdowns, multiple choice, matrix/rating, and more. Once you’ve created a survey, you can email it straight to your target audience from within the app. Recipients of the survey can complete it either in their SurveyMonkey app or online. The app collects and displays the results as they are received. Available in Google Play and the Apple App Store.
  5. Polaris Office – This app allows you to view, create, and edit Microsoft Office products such as PowerPoint, Excel, and Word. You can also view PDF documents. Using share capabilities, you can send documents to cloud storage services like OneDrive, Google Drive, and Dropbox. The app also syncs to multiple mobile devices. Available in Google Play and the Apple App Store.
  6. CamCard – This app eliminates the need to save business cards by allowing you to categorize them in custom groups. It uses your phone’s camera to capture the card, extract the name, title, and contact information so that it can be stored in the app. It also retains the image of the card. You can also choose to export the information directly into your phone contacts. Available in Google Play and the Apple App Store.
  7. Paper; Notes, Photo, Annotation, and Sketches – Are you the kind of person that likes to capture an extensive whiteboard session via your phone’s camera so you don’t lose the information? This app allows you to create an idea board and add notes, photos, and annotations pertaining to the idea that you’ve created. This is a great way to capture a photo and add some notes to help you recall the conversations and important decisions that stemmed from your whiteboard session. Available in the Apple App Store.
  8. Sunrise – Sunrise is a calendar app that aggregates all of your other calendars into one. You can add Google, iCloud, and Office365 calendars as well as events from Facebook, Eventbrite, and many other apps. It’s a great way to see what’s really happening in your life in one view. Available in Google Play and the Apple App Store.
  9. Moxtra – Moxtra is a team collaboration tool that allows teams and workgroups to connect and communicate with each other. Chat, share files and images, assign work items, and schedule meetings with your team. The app can send push notifications to alert team members of new content. You can create multiple groups to help manage all of your teams. Available in Google Play and the Apple App Store.
  10. DrawExpress Diagram Lite – This app is great for creating diagrams when you don’t have access to your computer. Using touch controls, it’s easy to draw shapes and connections. The app will transform your imperfect scribbles into beautiful shapes. You can also select from a multitude of stencil kits including workflow, Business Process Modeling Notation (BPMN), network, and wireframes. You can export your diagrams via email, Dropbox, and Google Drive or save it to your phone’s photo library. Available in Google Play and the Apple App Store.

There you have it. Using these apps will enable you to leverage your phone, a device that you always have readily available, to continue to innovate and engage your stakeholders even when you don’t have access to your computer. I am sure there are many other great apps out there that I’ve left off of the list, and I’d love to hear about them. What are your favorite apps?