Larimar Consulting

Usually when a Business Analyst is working on a project the client (which I’ll define as the party or stakeholder who receives the benefit of the Analyst’s services) and the customer (the party who is paying for the Analyst to render the services) are one in the same, at least from an overall organizational perspective (i.e. the client and customer belong to the same organization).  However, there are times when the client and customer are completely separate entities.

This sort of situation can arise in many environments.  For instance, the customer may be an association who wants a new software solution that will be used by its members.  Other times an entity may be required by law or regulation to provide certain services to other organizations and a project is struck to create a new solution to address these needs.  Regardless of the circumstances, having a separate client from the customer can put the Business Analyst in compromising situations, typically due to divergent needs between the customer and the client.

Typically when a Business Analyst faces a situation where various project stakeholders have differing goals, agendas, capabilities or level of engagement in a project, the project’s structure can usually help resolve differences that can’t be worked out through other means.  Within most project structures there will be a project sponsor or steering committee that is responsible for final decisions if consensus cannot be met.  However, in a multi-organization project the project’s structure may have little to no representation from the client base.  This may not be too surprising, particularly if the project was struck based on primarily internal consultations.

Often the Business Analyst is an advocate for those who will use the end result of the project.  To become an advocate one needs to empathize with the client base or else it is difficult to communicate the client’s needs to the other project stakeholders.  Once the Business Analyst understands the client’s needs they can often want to see those needs become fulfilled by the project.

However, the customer may not have the desire, resources or mandate to meet these needs.  If the customer for whatever reason doesn’t believe that some or all of the client’s requirements need to be met and the project structure does not lend itself to providing the client a voice at the decision table, the Business Analyst may find themselves having a hard time accepting the customer’s position.

When the client and customer are not the same entity the Business Analyst ends up in a type of agency problem; they’ve become an agent for the client whose interests do not align for the principal (the customer).   The Business Analyst was tasked with eliciting requirements for the client; if the customer in the end chooses to neglect some of these requirements it can be frustrating or disappointing to see the client’s needs going unmet.

Ultimately the Business Analyst will be faced with a choice to decide how far they will go in representing the client’s needs.  Since the customer has the ultimate authority on the project the Business Analyst must determine what level of conflict is healthy to ensure that the client’s needs are being met to the best of the customer’s ability given the overall project environment.  Obviously the Business Analyst should work within the bounds of professionalism, but there is a question at what point the Business Analyst should acquiesce to the customer’s expectations.

I don’t believe there is a simple solution or answer to this dilemma, and each Business Analyst will need to decide for themselves where the boundary lies if they encounter this situation.   Have you ever been in a situation where your role as a Business Analyst put you in conflict with the project sponsors or Steering Committee?  How did you deal with the situation?

As spring begins to plant its roots in the Northern Hemisphere, many people will begin an annual spring cleaning of their home.  All the clutter that has accumulated over the past 3, 6, 9, or even 12 months since the last cleaning is collected, assessed and then dealt with (either by moving stuff to a better location, actually using the thing, or throwing it away/selling it).

Like homes, most of us have a bunch of ‘to do’s’ that build up over time.  Whether you are someone who meticulously manages all the tasks that you must do or you are someone who will try and keep all their ongoing duties solely in your head, chances are that you have a list of things that you have wanted or needed to do but have never quite found the time to get around to.  I like to call the list of outstanding tasks that someone has to do (whatever their context; personal or work-related) a personal backlog.

While there’s nothing wrong with not crossing off all your tasks (after all, who really has time to do everything they need or want to?); over time you can develop a level of ‘accountability debt’ to yourself.  Most active and high-achieving people strive to get as much done as possible, and when they can’t complete everything that everyone has asked of them they usually take it personally, either at a conscious or unconscious level.  This could be manifested as internal guilt, frustration, stress or other negative emotions.

As you feel bad about not being able to accomplish everything you start to make more and more mental reminders of all the things that you haven’t been able to do as if this action itself will help get more tasks completed.  This action simply clutters up your brain, which has a finite amount of space for keeping track of things.  As your personal backlog list continues to grow, you end up crowding out more pertinent or relevant information from your mind.  This can lead to feelings of confusion or lack of focus on the tasks at hand that matter the most.

So, if you’re feeling like you have a million things on your mind, it’s time to perform a little spring cleaning.  This activity will involve 4 steps as described below.

Collect

Write down everything you can think of that someone has asked you to do or that you’ve pledged to do.  Nothing is too big or too trivial to be included in this list.  This should span your work and personal lives; don’t forget about promising to clean Aunt Martha’s eaves troughs (you know she won’t).    Include problems that you need to solve (for instance, figuring out how to make your sales estimates more accurate going forward or what to do about your son’s late nights) and that you may need some dedicated thinking time to properly ponder.

This may not be something you can do in one session, but allocate some dedicated distraction-free time to this effort.  You will be surprised how many little items come bubbling back to the surface once you get on a roll.

If you already have one or more to do/task lists, this is a great place to start.  For this activity you will want to consolidate all of your task lists into one big master list.  You may be used to segregating certain aspects of your life and find it effective to manage them that way, but from a spring cleaning perspective you will need to look at everything holistically.

Don’t be surprised (or daunted) if this list grows into hundreds of items; instead take satisfaction that you now have a single point of reference for all your outstanding action items.  You no longer need to carry these about in your brain’s short-term memory.

Break Down/Up

You will want to review your list for items that are not immediately actionable (that is, there is something that you would first need to do in order to accomplish the stated item).  Those items should be moved to a second reference list and be linked in some way to the one item that is currently actionable on the main list.

This way your to do list becomes a series of ‘next action’ steps, not some nebulous list of end goals that may have dozens of steps that need to be performed in order to be accomplished.   Having a list for achievable next steps will add value to this list when you’re looking for what you should do next or at a given moment.

Prioritize

Once you have your master list, it’s time to prioritize. The goal of this prioritization is to have a single ordered list from the highest priority item to the least priority item.

Some of you may want to categorize your items into work and life at this point.  I personally find that my life is not so easily segregated (and I would suspect that with modern working practices most people’s are not either), so I would suggest you try and come up with a single prioritized list.

Similarly, you may have a desire to have ‘high/medium/low’ or similar buckets and then just place all your tasks into one of the priorities.  While this may be a good starting point so you can manage prioritizing elements further, having buckets of items doesn’t help you actually get any of the tasks done later on.  When you’re in working mode, you will want to quickly scan the top of the list and see which of the items are actionable at the moment.  Having a list of 10-30 ‘high priority’ items doesn’t help you make a decision at that point, and can lead to feeling overwhelmed and helpless right at a time when you could be easily getting started to work on something.

If you need help getting started, associate due dates to the items that jump out at you off the page as stuff that has to be done by a certain time.  This should help you figure out where some of the items fit on the list.  Others may not have a set due date but still need to be placed higher up the list.

The end product doesn’t have to be perfectly prioritized; you shouldn’t spend more than a few seconds debating whether one item is above or below another.  The goal is to have a general order of importance based on your current life situation that can be easily referred to going forward.

Prune

Once you’ve prioritized your list, start scanning the items from top to bottom.  After each item ask yourself “do I really need to get this done?”  Once you start running into a steady sequence of ‘no’ answers, start looking for a place to cut off the list and remove all the items below it.  Then quickly scan the remainder of the items to see if there’s anything you actually do need to do and bring it back to the pruned list (or perhaps add a couple of items to your pruned list for ‘Sorry I can’t do this messages’).

You need to be honest with yourself and look at your available time, your other commitments and obligations and your personal energy levels and goals to figure out where the line should be drawn.  But you do need to draw the line somewhere; I haven’t met anyone who is able to accomplish everything that they put down when they’ve done a brain dump.

Ongoing Maintenance

Once you’ve done this activity, you now have an actionable, up to date and realistic list that you can use going forward to take on your tasks and duties.  If you use this opportunity to manage this list on an ongoing basis, you will likely find that your mind will be less cluttered and you will be able to easily find tasks that you can do in any given situation (e.g. those 10 minutes between your meetings) by keeping this list up-to-date and close at hand.

Spring cleaning can feel like a chore, but when you do it on your personal backlog the benefits of a clearer mind and the ability to focus easier without worrying about forgetting to do something can be a major energizer for the months ahead.

Stakeholder Analysis is an important and often ongoing activity that Business Analysts perform as part of their duties.  Solution delivery team members need to understand who else is involved or impacted by their work effort, how they can interact with these people or groups, and what sort of tradeoffs exist in pleasing one group over another.

The BABOK highlights several important dimensions that can be collected on each stakeholder, namely:

• The stakeholder’s attitude towards the project or solution team
• The stakeholder’s influence on the project or solution team’s success
• The type of stakeholder (internal/external, direct/indirect, etc.)

The body of knowledge also describes artifacts such as a RACI chart and stakeholder map to help manage the information you collect on stakeholders.

In addition to these dimensions, I believe that there is another consideration that needs to be included in stakeholder analysis: the stakeholder’s engagement level with the project or solution team. Read more »

First off, let me just say that I really like the BPMN standard, especially the 2.0 Beta specification.  I find the notation to be a powerful and expressive language that takes into account not only the standard elements in business processes but also considers all sorts of interesting possibilities that may arise.  I think the new Choreography and Conversation diagrams and additional event types open up new ways to describe intricate processes and collaborations between various individuals and organizations.  Indeed, BPMN allows you to graphically model almost any situation that you can find in a business.

And I rarely get to use it. Read more »

Meeting and workshop facilitators can often find themselves caught in the middle of several strong personalities trying to get their point across or convince others of their opinion.  When tempers flare the meeting might descend into a bastion of name calling, cursing, bruised egos and the potential for long term damage to personal and professional relationships.  As a facilitator, it is your job to help the group achieve their stated goals for the meeting.  But if discussion descends into shouting matches, what can you do?

Here are 3 tips that can help ensure that meetings move smoothly even when there’s the potential for personal conflict. Read more »

Business Analysts are often thrown into projects to help gather requirements around a known, defined problem.  Other times we’re asked to analyze the current state of a certain process, organization, system and look for ways to improve areas that are clearly lacking.  I’ve noticed that when we are brought on a project, the problems described are likely only surface symptoms to large issues.  For example:

• This system can’t handle more than X transactions per hour and it’s killing our procurement process’ performance
• This organizational unit doesn’t have the right staff to be able to keep up with the demands being placed on them
• This process is obsolete and overlaps with three of our other processes

While it’s great to have a problem identified, it is well worth the effort to ensure that you are analyzing a root cause problem and not only a symptom of a greater issue.  If you don’t do this step, you may end up using lots of resources at what amounts to a band-aid solution.

A great technique to help delve into a problem and identify possible root causes is the ‘Five Whys’.  When an issue is presented you ask the question ‘why did that issue occur?’  Once you have your answer, ask the question ‘and why is that so?’ Continue until you have asked ‘why?’ at least five times, even if you felt you’ve reached the root cause after 2 or 3 responses.

Joel Spolsky details a good example of how using the Five Whys can elicit solutions to underlying problems.  Recently I came across a similar example with a client (certain details have been changed).

Issue: Employees did not receive their pay stubs on pay day.

• Why? Because the printing system failed the day before pay day.
• Why? Because the system could not recover from a hardware fault.
• Why? Because the system uses outdated hardware that has no automatic redundant backup.
• Why? Because the system hasn’t been replaced as it hasn’t been identified as a high enough priority to allocate budget to its replacement in the current economic climate.
• Why? Because the organization does not have an enterprise planning methodology that weighs the risks of current operational systems failing versus the criticality of these systems and the impact of such a failure.

Some people may have been tempted to stop after the third or fourth question.  We could have rushed to find a way to set up either an automatic failover system or to increase the availability of resources to replace legacy hardware in the event of a failure.  Or we could have determined that the system needs to be replaced and develop a business case to do so.  But the overall challenge that faces the organization is a way to assess the relative risks of failure for all enterprise applications and come up with mitigation strategies in light of the available funds to maintain and replace systems going forward and to holistically evaluate the replacement of such systems over time.

It may still be a good idea to address the symptoms found during this activity.  In the end the root cause(s) that you identify may be deemed to be outside of the domain of you and/or your project team’s responsibility.  The key is to recognize that there are potentially larger issues that may need to be addressed; otherwise this issue may resurface with different symptoms in the future and to pass along this information to those who can act on it.

The Five Whys isn’t the only tool you may want to use to help identify potential root causes (here are some suggestions on how to improve its efficacy at finding root causes), but I believe that it can be used to quickly assess whether a problem that has already been defined may in fact be a symptom of greater hidden issues.

In many Agile projects requirements are not typically written in the form of a formal requirements document.  Instead, a collection of concise but effective means of describing what must be built called user stories are often used.  User stories describe the behaviour, performance, or interface of a system from a customer’s perspective.  A typical user story might look something like this:

As a potential customer I want to be able to view books based on the search criteria I entered.

User stories are not only effective requirements management artefacts, they are also essential to estimate the scope/size of the project and to track the progress of the team.  When determining the size of the project, teams estimate the level of effort required to complete each user story and then aggregate their results to come up with their estimate for the scope of the project (for more details on how to estimate level of effort in Agile projects, see Mike Cohn’s excellent book on the subject). Read more »

Sometimes you get in meetings where there a lot of diverse opinions present and a specific option must be decided upon.  If you’re not facilitating the meeting, you can easily (and justifiably) be focusing on the comments and dialogue that only align with your thoughts on the given subject.  You may find yourself wavering in and out of focus while others are talking, and are just waiting until you get your chance to speak again or for the meeting to be thankfully over.

Such actions are usually counter-productive to achieve the end result of the meeting (or process).  Furthermore, it’s likely that many other people in the room are doing the same thing as you – which can lead to deadlocks and bruised egos.

One trick I’ve found that helps me when I’m falling into this trap is to take notes from the meeting as I would if I were the minute taker, even if I’m not. I usually take fairly detailed minutes during the meeting and then summarize them for review after, and as a result I need to stay on top of all the conversation that is occurring.

I find this action forces me to focus on all sides that are being represented.  As I write down or type other people’s information or opinions, I find myself letting their arguments sink in at a deeper level.  This in turn helps me reflect on my own opinions and information and helps me accept the end result regardless of whether the decision I supported or not is taken.

What other techniques do you have that you use to help keep your mind open when you’re in a meeting or process that contains diverse opinions?

I am in charge of a relatively big training effort for a project (approximately 45 live training sessions in 10 weeks, as well as online training opportunities) to assist with the deployment of a new piece of software.  The live training alone will involve over 450 people and will be quite in depth and hands on.  Training often plays a critical role in the successful adoption of a new product.  Without the proper knowledge of how to effectively use a system, clients can become frustrated, ambivalent or hostile to the change that’s occurring, which can ultimately affect the success of the change.

As a result effective training methods are essential to ensure the ultimate success of the product and the project from which the product was spawned.  But how can we determine whether the training was useful, relevant, and appropriate for the given audience?  Like any other part of a project or initiative, we’d like to have some accountability on the quality of work product.  As a result it is important to come up with ways of measuring how successful your training activities are.

While surveys of trainees and the like can help measure the perceived quality of the training itself, on its own such information does not provide us with a true measure of the success of the training process.  You need to map the output of the training to its end goals and from there develop measures that will provide an additional level of understanding as to the quality of the training.

Establish Your Outcomes

First, you need to establish your target outcomes, the end results that you foresee as a result of the training activities.  Typically I start with qualitative outcome descriptions.  For my project, we want to ensure that clients understand how to use the software well and that they can operate the software independently (i.e. no need to ask for help).  We also want to ensure that clients realize how they can use the information available to them through the system to resolve data conflicts with each other rather than having to go through a third party.  Lastly, we want to reduce the need for a third party monitoring group to have to contact clients and enforce data resolution and processing activities.

Define Your Measures

Once you have your outcomes, you need to develop ways to measure these outcomes.  These must be quantifiable results that you can use to accurately demonstrate whether an outcome was met or not.  For example, we could use the number of calls and e-mails to the Help desk regarding the product as a measure for how well clients understand the software once the training is deployed.  We can also measure the number of times the third party is contacted to resolve a data issue between clients who work in different organizations.  Lastly we can count the number of times the third party must contact clients in order for data conflicts to be resolved.

If the training is related to an existing set of processes, you would ideally use measures for which you already have (or can gather prior to) the implementation of the product/solution.  This way you can have data not only post-implementation but also pre-implementation and analyze the impact of the product and the training.

Create Goals for Each Measure

Once your measures are in place, come up with target goals for each measure.  If you have pre-deployment data, your goals can be about trending rather than absolute figures (for instance, you could set a goal for a 20% reduction in Help desk calls regarding process X instead of saying your goal is to have less than 200 calls regarding process X).

These goals should be evaluated by the relevant stakeholders, approved by the project sponsor and become part of the project’s success criteria.

Some Considerations

If you’re implementing a product that is designed to improve an existing process you probably have some measures and targets for the productivity of the process itself once the product is deployed (e.g. increase order taking throughput per hour by 50%).  For these measures, training is only one of several factors going into the end result and cannot be easily removed to analyze the success of training on its own.

However, you could perform some basic ‘A/B’ tests with a limited subset of clients if you wish to determine how much of an impact training has on the product’s overall success.  Train one group of clients as per usual and then train another group with either a different set of training materials, style, etc. or not at all.  Assuming you control for other relevant factors that may impact the end result (e.g. level of experience of clients, demographics of clients, etc.) this can be an extremely useful to determine how important training was to the overall success of the project.

If not all of your clients have access to the same type or level of training try and segregate their data so you don’t make erroneous conclusions about the success of your training activities.

Deploying a new product, process, or system into the organization is only as effective as the individuals who implement the change.  Making sure that training aligns with the end objectives and can be measured to determine its utility is an important aspect of the overall project’s outcomes.

I seem to find quite a few job postings for Business Analysts that have a couple of lines in the ‘tasks to perform’ description that scare me like:

• Define test strategy and test plan
• Develop and execute test cases
• Perform stress and load test scenarios

It’s not that I don’t believe I am capable of these tasks at some level of competence; after all most BAs have had to perform these activities at some point in their career.  I don’t believe a BA should be expected to do Quality Assurance tasks.  I can understand the temptation to leverage Business Analysts to perform Quality Assurance tasks, namely:

• BAs already have a good understanding of requirements, use cases, etc. so it should be easy for them to come up with testing approaches and test cases
• BAs are ‘analytical’ in nature and thus are well suited to QA activities
• After the requirements are done BAs just typically sit around or are moved to another project, so we might as well give them something to do so they can be with the project for its entire lifecycle (and be held accountable for ensuring in the end user needs are met)

While these arguments all have some level of credibility, I don’t believe that having BAs perform QA tasks should be considered good practice.  Don’t get me wrong, I believe that BAs need to work closely with testers to ensure that requirements are well understood, that requirements can be traced end-to-end, and to help facilitate discussion amongst the team to develop a testing approach.  I don’t even mind having to execute test cases if the team’s in a crunch and need some more people to run through scenarios.  But overall, I believe that having a Business Analyst being in charge of testing activities (especially if it’s on the same project as doing BA tasks) is not a good idea for the reasons I discuss below.

Quality Assurance is a Separate Role

As the BABOK V2.0 has so eloquently stated, Business Analysis is about working with stakeholders within an organization to identify solutions that will help the organization meet its goals.  The BABOK barely mentions testing, only to indicate that a Tester is “response for determining how to verify that the solution meets the requirements defined by the Business Analyst.”  These are two distinct roles that while they involve leveraging common knowledge and artefacts (e.g. requirements) they definitively involve disparate activities, techniques, and tools.

Quality Assurance is its Own Profession

Not only is QA its own role, there are organizations that promote the tasks performed by testers as its own profession.  There are even separate bodies of knowledge, designations and certifications that have been developed around QA activities.  Like any profession it takes time to become adept at performing QA tasks, just as it does to become proficient at BA tasks.

While individuals may develop expertise in both Business Analysis and Quality Assurance over several years (in which case they can perform either role) it is unlikely that most BAs have the level of knowledge to adequately perform QA tasks.

Bias Inherent in Performing Both Roles

For me this is the most important consideration – if you are the Business Analyst (or one of the BAs) involved in the gathering of requirements, you end up developing certain biases based on your knowledge of the business and the problem(s) that are to be solved by the solution being developed.  Such biases are rarely at a conscious level, but do occur frequently.

The BA can become so intimate with the requirements that they may not realize when certain assumptions are undocumented, or may unwittingly ignore certain paths or scenarios that need to be tested because they understand the recourses that can occur in those circumstances.   In essence the BA may become so ‘in tune’ with the requirements as documented that they may omit or neglect circumstances or exceptions in testing plans that need to be considered.  An unbiased third party without such intimate knowledge would have a much easier time to spot any inconsistencies.

Such biases can impact the veracity of testing activities.  For example, if the BA starts to write test cases based on what’s in their head rather than what is documented, traceability can become an issue.  If the BA omits certain test case scenarios since they know that they are unlikely to occur, are not documented, or the BA already knows how the system will handle the scenario (since they saw it at the last demo), then not only is the current testing phase impacted, regression testing on future changes to the system can become compromised.

Lost Opportunity to Have Another Set of Eyes in the Process

As noted above, a BA can form a biased view of the solution and the project based on their work and job duties.  It never hurts to have another brain in the fold that is tasked with, among other things, finding holes in documented processes, looking for requirements that may be under-developed, and generally ensuring that the solution is free from issues that would cause stakeholders to reject it.  There are few downsides to including another person given the risks inherent with one person performing both sets of duties.

Get a Tester

Overall, if your organization has the capacity to have dedicated Quality Assurance professionals they will pay for themselves in spades (just as Business Analysts do).  Using BAs for testing purposes may seem like a slick thing to do, but in my opinion it is almost never the right choice given the option to go with a separate individual.

What do you think?  Leave a comment and let me know your experiences.  Have you been a BA who has been forced into QA duties?  Do you think there’s no issue with someone doing ‘double duty’?