Skip to main content

Tag: Business Analysis

CBAP Was Always ‘UnPretty’ – Do You Have the Courage to Embrace Synthesis

“Certified Business Analysis Professional” (CBAP) always seemed a little awkward for a professional designation. Those of us who got it early actually worked directly with people to take the test (no on-line then). I had some low fun teasing the exam team (Cleve Pillifant and team, thank you again) about the acronym. It was low of me since the exam team was available and the decision makers were not (shout out to Kathleen Barrett, hope you are doing well). To those whose eyesight is fading, the “B” can even be mistaken for an “R”. This is no big deal and is common enough (case in point “PMP”).

Now things change, because it is increasingly obvious that ANALYSIS (breaking into parts) is only half the battle (the easy half). The harder “half” is business SYNTHESIS. * Synthesis means taking the parts stated by stakeholders (requirements [stated]) and organizing them into possibilities by reducing confusions and artificial constraints (“but we built what they told us to build…whimper, snivel”).

Modeling IS simplifying. Simplifying requires doing something MORE, NOT LESS. Some of you will understand the statement “If you want it shorter it will cost more.” We know this is true because stakeholders are very reluctant to “simplify” the information they can offer. We also see this is true because we must reconcile wants across silos – often very committed silos.

Simplifying includes breaking concepts down (user friendly means more than a smiley face on screen) with analysis. It works by re-assembling concepts into understandable high quality summaries (models) with synthesis. More than ONE synthesis will be needed. One is for people who will read and follow the complexity. One is for people who won’t be able to pretend they are following unless the words are put into polygon shapes. “I’m visual” is the refrain, but more than four or five polygon shapes quickly reveal that the shapes have “words” anyway, and confusion reigns among the “visual”.

For productivity the experienced analyst understands that working in text can be faster than working in diagrams (at least for analysts that like working in text). An ideal situation is one where a technical writer engages the stakeholders in diagramming simple text while the analyst produces complex text.

Many diagrams are just fancy vague lists. Perfect examples are Visio and PowerPoint “flat” diagrams). As a productivity technique, drawings are easily outpaced by anyone who can create or follow an indented outline.

Here is a sample text “analysis” using the puzzle from the last blog (Everything We Needed to Know We Learned on Sesame Street):

  1. Business Requirements
    1. Business Goals / Objectives
      1. We want to increase sales
      2. We want happy customers
      3. We want to get rid of old technology because…
      4. More?
    2. Business Needs
    3. Capability Gaps
    4. Solution Approaches
      1. We want to buy this in ONE software package
      2. We want to outsource all software configuration and maintenance
    5. Solution Scope
    6. Business Case (what matters, how it matters and why it matters)
  2. Requirements [STATED]
    1. Every want is stated only, not modeled, verified or validated.
    2. All are vague – unspecific – need improvement
  3. Requirements [ANALYZED / MODELED]
    1. No want has been analyzed / modeled
    2. Even business objectives are unclear –
  4. Business Analysis Plan
  5. Solution Requirements
    1. Functional
      1. We want users to have the freedom to override business rules
      2. We want the system to pick the best approach
      3. We want to capture name and address and contact info everywhere
      4. We don’t want managers interfering with our work (micro-management)
      5. We want to reduce data entry errors
      6. We want direct access to the database
      7. We want users to write their own reports and not wait for IT
      8. We want easier, better scheduling with fewer disruptions
      9. We want large monitors, aluminum cases and wireless keyboards on our PCs
    2. Non-Functional / Qualities
      1. We want easy to use
      2. We want a consistent high quality customer experience
      3. We want reliability, maintainability, scalability and no irritability
      4. We will know it when we see it but no sooner
  6. Transition Requirements
    1. We must have everything built before release
    2. We don’t want to change the work or conditions

We may not agree on whether the above is “correct”. I think we CAN agree that it is not useful, complete or free of conflict. There are unspoken relationships (e.g., relation of “solution requirements” to goals / objectives). There are potential conflicts right next to each other. One example is when stakeholders want direct access to the database vs. fewer data errors.

What can fix this? SYNTHESIS! Are you a business analyst only, or a business synthesist* as well? Creativity isn’t just gums bumping – talk is cheap, watcha got that a project team could follow, that could make sense to those who cannot code ambiguity, confusion or wishful thinking? Most importantly – which statements deserve more focus, and which less? Which statements represent the highest requirements risks? What is missing for effective objectives? What would your process model begin to suggest?

Can any of my readers write a single paragraph describing a workable approach? Can anyone resolve the apparent conflicts by addressing high-level business issues? What do the stakeholders mean and can it be built to the joy of all? Hint: Start by synthesizing “bottom feeding” requirements into “top priority” business needs related to goals and objectives.

And remember – you can’t skip any steps in BA world for true enterprise systems. Pay it now or fail it later. Think of all the BA work (yes, its hard, that’s why stakeholders don’t do it) as leading to a quality groomed backlog. Good process, followed by good interface design followed by quality development is unbeatable.

When we “do what stakeholders want” we are not serving their goals. Not unless they happen to be information systems experts. You might as well try to build a skyscraper for a toddler – “I want the 50th floor to be ALL ice cream” they scream.

Remember to say yes, and to place ice cream fountains everywhere on 50. Make it the centerpiece of the project, so no one will forget which stakeholders insisted. Allow all the stakeholders to pick flavors for prioritization. Above all synthesize the other 99 floors with FAST elevators to 50.

Mo’ later, thanks for reading, don’t get lost in the trees OR the forest.

* Do I have to spell it out for you 🙂 ?

Don’t forget to leave your comments below.

Are Business Analysis Documents Becoming the Dumping Ground?

Few of the areas within the business analysis context are least understood and as a result the business analysis document becomes a dumping ground of the project content and activities.

Do these questions ring a bell?

  1. Can we avoid the BA documents to be a dumping ground or catch all for the project activities?
  2. Are the stakeholders trying to prescribe “detail tasks” instead of focusing on their actual needs?
  3. Does your stakeholder team get upset when you refuse to record un-related information in the BA documents?
  4. How do we make sure that un-related things are really those un-related things and it needs a bigger and better house?

As Business Analysts, you need to be cautious about the information which needs to be captured. You should be able to decide/comment on content of the document. The suggestions below may help you decide in the future should the above questions arise.

Few areas which are least understood and could be improved are listed below:

  1. Assumptions: Make sure you have a clear understanding of each of the topics of the document. For ex. If there is an Assumption section then to make sure that the assumptions are minimal and purely related to the requirement analysis activities instead of the project activities. Also the exact meaning of Assumption is “a thing that is accepted as true or as certain to happen, without proof”. If your statement clears this test then it is considered as an assumption.
  2. Functional Specification: In the name of functional specification, sometimes the stakeholders are tempted to provide step-by-step and task-by-task description so that the information is not taken out of context. Make sure that the specifications do not contain step-by-step information. For ex: Do this once you have done this.

  3. Business Rules: These are policy statements which do not change over the period of time. It only changes when business changes the way they are doing business.

  4. Business Metrics: Be cautious about the business metrics as it should not include project metrics. Rather it should capture the metrics which would be impacted because of the new/updated business needs.

  5. Repeating: Sometimes the stakeholders become overcautious and they would like to state the same thing in different words in different parts of the document. Make sure that you communicate and emphasize the importance of information overloading.

These were some of the areas which I thought need to be watched carefully while you are dealing with different stakeholders. I am sure there will be several different areas like the above where the business analysts need to be cautious about the content. The idea over here was to provocate thoughts in your mind on this topic. 

Don’t forget to leave your comments below.

KISSing Complexity Goodbye

As I was reviewing the presentations from this year’s Building Business Capability conference, I kept running into slides that looked like the graphic below to describe frameworks which model how organizations operate (the details have been left intentionally blank to protect the innocent):

Hailes Nov18
The Everything Framework

In this one example there was no less than 13 different model components and 25 relationships defined!

One of the recurring themes I heard from presenters and attendees alike was the challenge in demonstrating the value of business analysis and related activities to their organization, particularly with business architecture initiatives. I think part of the challenge lies in trying to use big, elaborate frameworks to describe anything and everything within an organization. Sometimes we think we’ve developed the ultimate map of our organizations, but it just serves to confuse our audience when we try and have a conversation with them. It can be hard to explain, much less understand.

Complexity – the conversation killer Watch video here

Instead of trying to have every possible model and view of our organizations, why not focus on using what is effective and relevant for our audience and eliminate the rest. One of the primary purposes of modeling is to facilitate a shared vision of the present and/or the future, which supports informed decision making and improves change outcomes. The more complex we make the model the harder it is for all stakeholders, from executives to front line staff to solution experts, to get on the same page.

Every organization is different, so no one set of models is appropriate for everyone. Here is a sample of the types of models I usually use as a starting point with clients:

  • People: Org charts and stakeholder/actor/persona matrices
  • Capabilities/Processes: (Non-compliant) BPMN diagrams
  • Information: Entity-relationship diagrams, sometimes data flow diagrams, business rules catalogue
  • Technology: Systems catalogue mapped to the information each system manages and the processes it supports
  • Requirements: Text, diagrams, mockups/prototypes

This is the starting point that I use for everything from developing business cases to assessing solution performance. These are by no means the only models that can be used to maintain and communicate this information; it’s all about finding what works best with your stakeholders to achieve that shared vision and reduce the noise in your conversations.

So, what part of your business analysis practice do you consider overly complex? What challenges do you encounter due to the complexity? What can you do to simplify or eliminate items that are not having their desired effect?

Don’t forget to leave your comments below.

The BA Role: Has it really changed in the last 15 years?

As I tweet my latest BA adventures, I ask Siri to find the best restaurants near my hotel, Skype with friends in Mexico, and order my favorite bottles of Napa Valley wine on Amazon, I can’t help but be amazed by how much technology has saturated my life in the last 15 years.

Internet, email, mobile devices, “the cloud” and social media have transformed the personal and professional lives of a huge portion of our world’s population in such a short amount of time.

Visionaries like Bill Gates, Steve Jobs, Jeff Bezos, etc. get most of the media credit for the technology explosion, but instead of focusing on their undoubtedly awesome leadership, I often find myself thinking about project teams. I think about the thousands of programmers, project managers, architects, testers, and of course business analysts—that move the vision to reality.

Given this technology explosion, one would expect that the tools, processes and procedures used to deliver technology have evolved dramatically in the past 15 years as well.

What do you think? Has project life changed in the last 15 years? A lot, a little or not at all? When focusing on the BA role, have the primary functions of the BA evolved? Have BA tools and techniques changed? Have the deliverables changed?

Have the mindset and behaviors changed?

Here are a few thoughts about how project life has changed and how those changes impact the BA role:

Higher Stakes

Whether a project delivers solutions to internal or external customers, the stakes are higher in 2014 than they were in the 1990s. In the past, system and process errors often had manual back-up procedures. The people around then still remembered what the business rules and logic are.

Now, we are so dependent on technology, that, in many cases, business shuts down when the system does not work— orders don’t process, inventory does not move, money doesn’t flow, customers/employees jump ship.

These high stakes impact the BA role in the following ways:

  • Accurate requirements become even more important than in the past as customers and operations are impacted more when requirements are missed.
  • Contingency plans for key functions become critical to protect employee/customer relationships.
  • BAs become risk managers and need to effectively communicate risks, dependencies, and constraints so that projects do not move forward with bugs, gaps or inefficiencies that will compromise the value of the solution being implemented.
  • The partnership between BAs and QA (test teams) needs to be stronger. BAs need to help QA prioritize test cases and provide context and expected results for key test cases.
  • The partnership between PM and BA needs to be stronger than ever, both managing key aspects of value, risk, and complexity impacting how both roles work with stakeholders and manage scope and priorities.
  • A competitive environment in most industries that changes quicker than most project can keep up. This means high stakes if teams cannot flex to the changes, BAs need to be able to adapt and work with changing requirements to ensure the most value is delivered.

Increased Complexity

Fifteen years ago, most BAs were probably working on in-house software/process projects that involved 2-3 systems and a multitude of manual paper procedures, supporting a single business unit or product. The entire project team probably shared space on one floor (or even one large room) and many of the stakeholders were just a few floors away. BAs often grew to understand systems and processes so well, they did not need extensive assistance from subject matter experts.

Business and project complexity grows as companies expand and merge, and it’s happening more often and faster than before. In many cases, dozens of systems interact, integrations and interfaces are critical and complex, users expect more form systems, and BAs gather information from people across the country and even across the globe.

Increased complexity pushes BAs to:

  • Strengthen their elicitation techniques to account for the immense amount of information complexity, and cross-functional connections; amounts no single person can possibly keep up with as their own knowledge base.
  • Transform elicitation skills and techniques to discover requirements that are unknown when the project starts. Helping the team discover requirements they did not know they had, but add immense value to the changing landscape.
  • Strengthen analysis techniques to make the critical connections between functions, processes, rules, data and user experience end to end.
  • Increase the use of collaboration techniques. In the past, solutions may have been more obvious. Now defining solutions for complex systems requires meaningful collaboration from a diverse group of stakeholders who are rarely in the same city.
  • Strengthen their facilitation techniques to help stakeholders focus, prioritize, and discover requirements as we learn together.

More vendor package software

Packaged software purchases from third-party vendors also add complexity to projects. Organizations assume packaged software solutions offer reduced costs and efficient implementation and are surprised when project delivery is not seamless.

As organizations expand their use of packaged software, BAs must:

  • Define vendor roles and responsibilities, especially understanding the role the vendor BA and client BA. The vendor BA’s role is to be a functional expert of the vendor application, functions and options. The client BA needs to be the voice of what the user and process goals and business rules are to meet the solution objectives.
  • Quickly build strong and trusting relationships with vendors, yet keeping vendors accountable for bringing options and alternatives to realize requirements.
  • Understand and evaluate vendor requirements strategies, and options to meet requirements. Escalate any related issues that would impact solution value.
  • Quickly map current systems/processes to packaged software process/functions. Understand and communicate gaps and changes to stakeholders. Prototype, pilot and test quickly to understand requirements and designs fully.
  • Understand when to leverage vendor knowledge and when to leverage business knowledge to ensure value from the package.

Less time to do requirements

Time and cost have always been focus of solution delivery. Organizations apply strong pressure on their project teams to deliver solutions faster. Our stakeholders have less time too, which means we need to alter our practices to work more efficiently.

In recent years, this pressure has resulted in tighter timelines for business analysis and requirements. With increased complexity and shorter timelines in 2014, BAs need to:

  • Reevaluate BA practices and techniques to maximize efficiency.
  • Reevaluate how we use meeting time, collaborate more, and in smaller groups to get work done.
  • Reevaluate how we document requirements; watch our level of detail for each audience; document in pieces and context rather than big requirements documents.
  • More alignment to other projects needed to integrate value across solutions.
  • Understand and communicate solution priorities and risks; base the requirements and testing plans accordingly.
  • Ask for more time if needed with a solid plan in place to provide value to the stakeholders, and identified risks in business terms if time is not allocated.

Agile Approach

In the 1990s, most BAs worked in a traditional waterfall environment where templates were the norm and the software development life cycle was clearly defined with a regimented organization-wide or application release schedule.

Many organizations continue to operate in this fashion, but more organizations are trending to using an Agile or hybrid approach to deliver solutions.

The role of the BA in projects using an Agile or hybrid approach can be a bit ambiguous, but in general this Agile or hybrid approach compliments a movement toward more collaboration and flexibility in solution delivery, and less focus on SDLC process.

BAs working on projects using an Agile or hybrid approach need to:

  • Utilize techniques that inspire collaboration and meaningful dialogue to generate effective and innovative solutions.
  • Understand their role and how it adds value to the solution delivery.
  • Understand timing and deliverables may change, but mindset and what we do as a BA does not.
  • Advocate for the value they add to the project.
  • Let go of role definition based on governance processes and focus on the essence, value, and goal of what you do as a BA.

How has your BA role changed over the years? Are you still generating 100+ page BRDs?

Don’t forget to leave your comments below.

I Am Not David Blaine

“Hello. I am not David Blaine. Nor am I Penn and Teller or Miss Cleo. I am a Business Analyst, and I am here to ask questions and get to better understanding of your business and needs. I am not here to read your minds or predict your requirement changes 72 months from now.”

Do you ever feel the need to start conversations off like this with your business partners? I feel that way all the time. And I certainly do not think I am alone in that feeling.

Like anyone else, business partners tend to be completely caught-up in their own world. They know their business like, well, the back of their hand. Skipping steps, information or needs that should be a factor in future design or program functionality happens and it is not done on purpose by any means. This is just a side effect of knowing an area so well and forgetting that outsiders do not have the same tribal knowledge. Remember, often times, Business Analysts are brought in to work on a singular project and business owners often have multiple projects going on at once. What might be majority of a Business Analyst work may be a tiny part of the business partner’s day. This is true of any industry and any methodology. Being Agile or Waterfall or Kanban is not a free pass on experiencing these pains.

Is there a way to avoid this situation? The short and true answer is NO; requirements will be missed and you will not find out every possible detail of their job that you should probably be aware of. Unless you are in fact a magician with telepathic powers. If that is the case, then please set-up a conference and teach us all your skills! So how can Business Analyst work to combat this inevitable situation? Among the many different tips or tricks, below are the three most common.

Job Shadowing

One way to overcome this is to job shadow your business partners. Not just speaking with the SME (Subject Matter Expert). Sit down with the actual business end user of the software or program. Who uses the application every day? Who would notice a change the most? Sitting down with the SME’s is critical and should never, ever be overlooked. But often times, our conversations tend to stop with the SME’s and leadership. Take a few hours at the beginning of the project and get into the weeds and get the perspective and opinions of the end users. I ask to be trained like a new person joining the team that you want doing the job on their own in the next 48 hours. Ask ‘why’ and ‘how come’ often and keep strategy and future state in-mind. Ask them thought provoking questions that they might not have ever thought about. Go back to them throughout the project and get their opinions. Show them mock-ups and story boards. An awesome side effect of doing this is you can end up with a person or a team that will be more than willing to help QA work later. And – BONUS – you get some nitty-gritty information that SME’s and leadership might have overlooked.

Write it Down

Sometimes, business partners need help remembering what they said was a ‘must have.’ This can be especially true if you use the Waterfall methodology. They may remember a conversation having Outcome A when you remember it having Outcome B. How can this be avoided? Take. Good. Notes. Do not rely solely on your memory or the memory of those around you. Write it all down. Things to consider in your notes:

  • The meeting or discussion date
  • The attendees and contributors
  • The topic at hand
  • Key pieces of information and decisions made
  • Who is following-up on what and when are the follow-up’s due back to the group

This does not mean you have to write down everything that was said. Remember, you need to be listening and participating more than writing. After you have cleaned-up your notes a bit, email them to the group. That way they can help correct any confusion and they have a record of the discussion and decision too. This will be a win in your corner when business changes their mind or contradict themselves down the road when discussing requirements and acceptance criteria. In a way, having all the information written out, shared with the group and saved allows you to be a pseudo Miss Cleo. I mean, you are predicting that they will forget what they said six weeks ago.

Ask..and Ask Again

More often than not, we are put on a project that covers a business area we are not familiar with. This is especially true if you are a consultant going into a new client every six to nine months. The great thing about this model of work is that you learn a lot about many different areas. Your breath of skill gets wider and that can lead to more opportunity for long term growth in your career. At the same time, it can leave you feeling a bit frustrated. It is important to keep in mind that you are learning another group’s work (or multiple groups work) and having to understand a job they have taken years to master. Always ask the questions until you truly understand. Never assume something works one way or is there for a certain reason. Do not be afraid to admit to your business partners ‘I do not understand. Can you please explain it to me again?’ They will be willing and, if they seem irritated, just reassure them that the better you understand this in the beginning, the better their technical solution will be. You cannot write requirements, acceptance criteria, project charters or anything else unless you have a firm understanding of the business and their needs.

You are not a mind reader that can zap information out of your business partner’s head. You can, however, anticipate certain behaviors. You can anticipate business SME’s and leadership having a ton on their plate and juggling multiple projects. You can anticipate they will not think of everything that needs to go into a project’s requirements and that they will change their minds on requirements, especially if the project is over an extended period of time. Last but not least, you can anticipate you not understanding everything in the business. Do not go out and by a crystal ball. Instead, take the time to implement certain behavior in your own routine that will help you and the project. Talk to more than just the SME; get to know the the end users. Get their opinions and input. This will make them feel more connected to the project and what you are changing. It will also help you find out details that leadership might overlook. Write down your discussions and key information. We cannot expect to keep everything in our brains and expect others to remember conversations in the same way. Be sure to send your notes to the group so that they have the same information you have. And never be afraid to ask the questions to your business as often as you need. The end result will be a better project or product because you have more details to work with. No project or product change is flawless; but following these three simple steps and remembering that you are not a mind reader will go a long way.

Don’t forget to leave your comments below.