Skip to main content

Author: Angela Wick

What is Your Modeling Mindset?

Written by Angela Wick on . Posted in Articles. 1 Comment on What is Your Modeling Mindset?

Pictures are an important part of BA work. Whether you call it modeling or diagraming or mapping or drawing, the techniques BAs use to turn processes, relationships, ideas and tasks into pictures, remains a valuable technique for nearly every phase of project work.

From spontaneously sketching ideas on a whiteboard to solve a problem during a meeting, to high-level conceptual models to define scope, to full scale data diagrams to look at detailed data requirements; our work demands a visual approach. Words have their place of importance, but pictures bring value that text and dialogue simply can’t.

“Of all of our inventions for mass communication, pictures still speak the most universally understood language.” –Walt Disney

And yet, while the importance of pictures seems obvious to many, some still do not use pictures and models as part of a regular approach to requirements. They discount the value of visuals or lack the skills and confidence to produce effective visuals.

Even BAs that passionately advocate the use of visuals disagree about why they are important and how they should be used.

So, what’s your modeling mindset?
Where are you on the visual continuum?
Are you using all text or all pictures or are you somewhere in between?

Mindset #1: I don’t need a picture.

Many organizations manage project deliverables and documentation with templates. Traditionally, many templates like the Business Requirements Document focus solely on text as required elements of the document. The text might be organized well and easy to read, but it’s difficult to understand context.

Your busy stakeholders need a way to understand, at a glance, what part of their world the solution and/or your document describes or impacts. What’s in it for me? (WIIFM)—that’s what the stakeholders want to know when they browse your project documents. WIIFM is so much easier to locate in a picture than by skimming dense text. Pictures also make it easier to see connections and relationships between elements.

Even if your template does not include a space for visuals, make space! Just because your template does not require a model or a diagram, doesn’t mean that you can’t add one.

Mindset #2: Models are a deliverable.

Some organizations approach models and diagrams with a “because I’m supposed to” mindset. Their standard BA task lists might include a process model, a user interaction diagram, and a data flow diagram. Instead of thinking about how to use visual artifacts to bring value to the project, the visuals just become an item to check off the “to do” list. If your organization’s culture on visuals sounds like this; challenge yourself to draw outside that box and bring visuals back to life for the purpose of dialog vs. a checklist.

Mindset #3: Models validate requirements.

Pictures, diagrams and models help BAs validate requirements. Strong BAs create multiple models and diagrams to help themselves understand and analyze requirements, and each stakeholder validate requirements at their appropriate level of detail. The models help everyone visualize products and processes. Requirement gaps and errors become more obvious than they would be in text only documents.

Mindset #4: Pictures start a conversation and take the conversation deeper.

Dialogue is the primary benefit of visual artifacts! Pictures get conversations started and pull conversations to a deeper, more meaningful place. Using this mindset, BAs can combine visuals with great facilitation techniques to engage ALL stakeholders and boost collaboration and creativity in areas of project work.

Mindset #5: Diagrams and models are technical and for the developers

When some organizations make the leap to visual communication and they get really serious about their pictures, the notation used, and the details. These are models and diagrams for the technical audience. These can be useful for technical collaboration, but not at the expense of the bigger picture.

Mindset #6: All I need is a picture.

Can a picture replace words? Do you need text documents to supplement user diagrams, or process flows, or product supply chain maps? Pictures and text accompanying one another are magical!

There might be projects where a well-functioning team can create a cycle of collaboration and prototyping (working pictures), diagrams, sketches, and models that do not require text. They may have a unique understanding of context together and are all aligned on the context and connections together. Most teams do not have this level of shared understanding with out a combination of pictures and text.

Wrap Up

In general, I am seeing that organizations don’t do enough modeling. Project teams need visuals to inspire dialogue and get people to look at things in different ways.

“When words become unclear, I shall focus with photographs,” said renowned American photographer, Ansel Adams.

BAs should focus their models and diagrams with their stakeholder’s perspective in mind. Some things to think about when working on your next visual?

  • Is the picture defining a concept or details?
  • Is the purpose to generate dialog or confirm dialog?
  • Should the model have a system perspective or a user perspective or a product perspective?
  • Who is contributing to the model, reviewing the model, or approving the model? What’s in it for them?
  • How you can use pictures to shine a light on gaps, issues, dependencies, constraints and risks.

Start experimenting. Find new ways to use models and diagrams to engage stakeholders and boost collaboration! If you have a favorite visual tool or technique, please share it by leaving a comment below.

Don’t forget to leave your comments below.

5 Lessons from Working with Agile and Waterfall Teams

Written by Angela Wick on . Posted in Articles.

Over the course of my career, I have always been intrigued by leaders who promote a specific methodology or tool or process as THE RIGHT WAY to deliver solutions. They dispense mandates and proclamations to promote their all-or-nothing, purist approach to methodology. Typically it is because it worked in the past for them, and once it fails to deliver results onto a new one.

I’ve seen so many CEOs, CIOs, CoE leaders, and technology directors come and go with their unique methodologies and approaches. Do you know what doesn’t change?—the way BAs do work to be successful; The BA mindset, the key tasks and core set of techniques, remain constant.

We may need to use a new tool, try a new technique, a different template or learn a new set of acronyms, but the mindset, tasks, toolbox still work regardless of methodology.

Success and failure do not discriminate by methodology either. I’ve worked with teams that consider themselves Waterfall, Agile, hybrid or generic. I’ve seen huge success and mind-numbing struggle in all types.

I find myself in the midst of the following questions and thoughts often: Does methodology really matter? Does the BA role change based on the project approach? Are Agile and Waterfall really opposites? Can we apply Agile principles to traditional environments? Is innovation really dependent on a particular methodology? How can we boost collaboration regardless of methodology?

Here is what I’ve learned about Agile and Waterfall approaches:

1. We need more collaboration in EVERY project.

What happens after your morning SCRUM or status meeting? Does everyone wander back to their cubes and belly up to their keyboards for the rest of the day, and meander into boring meetings?

Collaboration should be an all-day event! The occasional prairie-dog-pop-up to ask your neighbor a question is not enough. That’s not collaboration!

Lightening does not strike at your desk—you need to get up and get moving. Good collaboration is physically and mentally engaging. It’s not sitting at your desk or lounging around a conference room table. It’s a group of active people standing at a whiteboard with lots of dialog and movement. It’s a small group taking a walk and sharing ideas.

What about conference calls? Meaningful collaboration is harder over the phone, but it’s possible. Virtual collaboration does not involve one person reading a document and asking for feedback. It’s a group of people—not multitasking but—adding, moving, deleting from a virtual whiteboard. It’s a lively discussion where everyone contributes.

Even after years of Agile, many organizations still don’t collaborate enough. Too many teams still delegate work to individual desks and then throw it over the cube wall to their sequestered neighbors.

Teams should use collaboration techniques to see the big picture, to fully engage all stakeholders, and to generate more conversation and dialog.

2. Agile projects have BA tasks.

“Agile” roles, like Product Owner and SCRUM Master, are not all encompassing, neither are any of the Agile methodologies. They are not meant to accomplish everything needed to deliver a solution. Traditional BA tasks are still needed in Agile. You may or may not need the title of “BA” to do those tasks, but the tasks remain relevant.

Planning, monitoring, business need definition, communication, elicitation, requirements validation, traceability, etc. still happen in all projects. The factors that change might include timing, duration, emphasis and documentation. Rigor and adaptability might vary as well, but the basic BA tasks apply in all projects.

In an Agile project environment, you might replace the 400-page requirements document or the exhaustive, step-by-step process models with an evolving prototype or a sticky note-filled whiteboard with dry erase arrows. Either way, the fundamental tasks remain the same despite methodology. The BA uses many of the same techniques to get to the differing outputs. They may use the same technique more or less collaboratively. I hope it’s more collaboratively no matter what approach is being used.

3. Techniques don’t change.

Just like BA tasks, BA techniques don’t change based on the project methodology either. You may try new techniques in new ways at different times, but, all in all, good techniques can be used in Agile and waterfall environments.

Traditional methodologies require techniques for requirements elicitation, analysis, prioritization, change management, issue resolution and more. Projects using an agile approach require techniques for the same functions. It’s really just the external stuff that changes—the timing, structure, format and process. Certain Agile methodologies use a specific set of techniques (SCRUM  User Stories), but they are not all encompassing for requirements activities, they are a minimum to start with, a placeholder for conversation and more collaboration to follow.

We need to elicit requirements from stakeholders for every project. BAs on traditional projects might elicit all requirements at the beginning of the project. BAs on Agile projects might elicit requirements in one small chunk at a time, but the techniques are similar.

4. Stop Polarizing Agile and Waterfall

Agile and waterfall are not opposites—they are not mutually exclusive. Agile is not meant to be a polarizing force that pushes teams away from Waterfall.

Agile is a mindset born from the Agile Manifesto written by 17 men, probably on a napkin, at a Utah resort in 2001. Have you read it? It’s remarkably simple and packed with common sense:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

The intention of the Manifesto was not to replace a particular methodology—instead, the authors wanted to bring visibility to what works to build better software by:

  • Balancing the scales and slide away from the slow, document-heavy, procedural methods of the time
  • Bringing flexibility and fluidity back into the world of software development
  • Creating an efficient and effective process that would bring meaning and purpose into every task

Take note: The manifesto offers values, not demands, process, or requirements. They are meant to guide or refine, not constrain. These values can be applied to all projects.

I don’t think the authors of the Agile Manifesto meant to create such polarization in the industry or organizations and their practices.

5. Don’t freak out your stakeholders.

So given the simple foundation of the Agile approach, the transition to Agile does not need to be an historic event full of pomp and circumstance. Yes, Agile looks and feels a bit different than waterfall, but that doesn’t mean you need warn your stakeholders about major changes. Many of the agile principles can be implemented well on Waterfall projects without alarm or need for major change management. It takes relationship skills, facilitation skills, and confidence.

It is important to help all stakeholders understand the agile mindset, but we don’t need to overemphasize differences. Think about it this way: Why and how will it look and feel different? Is Agile driving the differences or is it just a better way of working?

It really doesn’t matter what it’s called, you just need to help stakeholders understand the value and move them forward gently. Any methodology done well will provide stakeholder value. Keep them focused on the output and how the process gets them to the value. As long as you are efficient, organized, effective, you will keep stakeholders engaged.

It may be the comfort of governance and process they are missing the most when transitioning to Agile. Help them through this, but don’t let it get in the way of being more collaborative and value minded working through requirements.

So, now that I’ve had my say, do you agree? 

Don’t forget to leave your comments below.

Sticky Situations: How do Business Analysts Influence Ethics?

Written by Angela Wick on . Posted in Articles.

We’ve all found ourselves in sticky situations at work—those grey areas between right and wrong that really test our ethical boundaries. The nature of BA work, facilitating change and protecting stakeholder value, launches BAs into the middle of many sticky situations. We often know things before the masses, we are present when new ideas float for the first time, and we work projects before risks, assumptions and regulations are fully flushed out.

In many cases, decision paths are murky—right and wrong are not obvious. In other cases, greed or tight timelines tempt people to take questionable shortcuts.

BA ethics encompass more than just your own behavior and choices. They force you to stand up for the rights of others including your stakeholders, your team and your industry.

Risk is often rewarded in business, but how do you know when the ethical line has been crossed? How can BAs, with their limited authority, influence others to stay to the right? Let’s answer these questions by taking a look at 5 ethical dilemmas commonly faced by BAs.

Scenario #1: Office Space

The Ethical Dilemma: You remember “The Bobs” from the movie Office Space? Well, many BAs are “Bobs”—they identify and promote organizational efficiencies. When organizations get more efficient, people tend to disappear. So, if your project scope includes “position reductions/eliminations” due to technology or process efficiencies, what should you do?

What not to do: Don’t spill the beans before knowing the sponsors plans and intentions. Also, don’t assume too much—these are very complex situations with legal, compliance, and people/performance implications. The sponsor may not be able to be share details with you.

Suggestions: It’s quite common that BAs learn about organizational strategies and priorities well-before the affected employees. BAs often interact directly with the affected teams to gather information for the projects that will eliminate team jobs. Here are a few tips for managing this awkward scenario: 

  • Ask the sponsor how she is planning to handle the position reductions. Does she have other plans/jobs lined up for the affected employees? Does she have a compliance plan she needs to follow?
  • Understand the communication plan. Find out when/how affected people will be notified.
  • Run through a few scenarios with your sponsor to understand the key messages that should be communicated if questions arise while you interact with affected teams. You need to be equipped with the right information to treat people respectfully and ethically.

Scenario #2: Martha Stewart

The Ethical Dilemma: Technology, process changes, and/or new products accompany strategic moves in many organizations. BAs tend to be on the front line of these changes, helping companies understand business needs, building requirements, analyzing impacts, etc. This means BAs have insider knowledge—knowledge that could be used for financial gain or for minimizing financial loss.

So, what would you do if a close family member owned a significant amount of stock in your company and you were in a position to see great success or huge failure coming around the corner?

What not to do: Do not end up in jail like Martha Stewart. She received insider information about the negative results of an FDA drug trail and sold the drug company’s shares right before the news went public. Stewart was convicted in 2004 and served a 5-month sentence. (Allegedly, Stewart lost the prison’s holiday decorating contest.)

Suggestions: So, do not share insider information with family members, friends, acquaintances or even strangers. Make sure you understand the rules and regulations before you buy or sell any investments associated with your current company, client, or their vendors/partners.

Scenario #3: Competitive Advantages

The Ethical Dilemma: Competition is fierce! Companies use extreme measures to maintain even small bits of competitive advantage. Companies guard their secret recipes, their pricing strategies, their new product ideas and marketing tactics. So, what would you do if you discover knowledge of a competitor from a family member (or vendor) impacting the direction and assumptions on your project?

What not to do: Don’t act on your competitor knowledge without understanding the potential risks.

Suggestions: Your first step should be research. If the knowledge is public information, then you may be free to use it to benefit your project. If the information does NOT appear to be public, then proceed cautiously. Understand the potential impact to the project and consider seeking legal advice to protect your interests and the interests of your company.

Also be cautious of the reverse dilemma—As BAs we often have information stored in our heads, laptops, tablets, smartphones that our competitors would love to gather. Whether they are thriving or failing, don’t discuss sensitive projects in public forums. You never know who is sitting at the next table or who is friends with your friends on Facebook. Don’t hurt your company’s reputation or give your competitors an advantage.

Scenario #4: Global Solidarity

The Ethical Dilemma: Many BAs work for large global corporations. Offshore labor helps large companies reduce expenses and remain competitive. In the best situations, these offshore arrangements boost developing economies and offer training and opportunities where options were limited. But what if you were on a project where a solution on the table involved offshore labor in a country with a poor reputation for worker’s rights?

Suggestions: Just like the last scenario, avoid assumptions. Your fist step should be understanding how the solution originated and why the specific country was chosen. You should also understand the discussion stage—is this one idea out of 100 in the initial brainstorming session or is the solution in the final stages of approval?

After you understand the solution history/path, then, you should focus questions around promoting and protecting stakeholder value:

  • What is the risk/reward to the stakeholders?
  • What are the risks to the greater organization?
  • Can you minimize risks? Can your organization establish ethical offshore practices in this country despite the country’s reputation?

What not to do: Avoid making it personal. Your personal opinion is important, but it should not be the focus of your discussion and actions. Provide a context for evaluating the solution that is framed, preferably with good research and data, in the best interest of the sponsor/stakeholders.

Scenario #5: Copycat

The Ethical Dilemma: In this age of information, it’s hard to track the original source of many ideas, images, articles, and studies. People forward, share, retweet and repost. We know copyright laws exist, but they seem ambiguous and very hard to enforce. So what would you do if a colleague asked you to copy something from a book or presentation, written by someone outside the company, and use it internally?

What not to do: Don’t make a practice of ignoring copyright laws. It opens your organization to legal and financial risk; it also compromises your professional integrity when others see work that is not yours not referenced or protected. This is an easy way to unknowingly build mistrust as many will know the work is copied but not call you out on it. If you see work copied, you need to call the person out on it and remind them of copyright protection obligations.

Suggestions: Copyright laws might seem like a petty, minor concern. No one gets harmed physically, and consequences seem unlikely. However, illegally using copyright protected materials creates financial loss for their creator. For example, sharing bootlegged movies limits the total number of movie purchases and essentially steals money from the creators. On our project as BAs we come across vendor and consultant materials, training materials, educational institution materials, industry and conference materials; all of these even when paid for are likely subject to copyright protection. So, please respect copyright laws as follows:

  • Get permission. Contact the owner and ask for the rights to reproduce the materials.
  • Site your sources when you reference copyrighted materials.
  • Negotiate/Verify use agreements with vendors. Partnerships with third parties usually include contract language about use of copyrighted materials. If you want to reproduce vendor materials, make sure this language is included in the contract. If you are already under contract, verify the copyright language before you reproduce vendor materials.
  • Review basic copyright laws with your legal team or by visiting http://www.copyright.gov/laws/.

Maintaining strong personal and organization ethics are a critical part of the BA Role. As protectors of stakeholder value, BAs must consider a broad range of project risks including those associated with business ethics, regulations and laws.

Have you found yourself in any sticky ethical situations? 

Don’t forget to leave your comments below.

Don’t Force Typical Templates on Packaged Software Projects

Written by Angela Wick on . Posted in Articles. 1 Comment on Don’t Force Typical Templates on Packaged Software Projects

One of the most interesting trends I’ve seen in my business analysis career is the shift from custom software development to package software implementation.

Traditionally, large corporations created in-house teams that supported business functions by developing software from scratch. Gradually, package software made its way onto desktops via word processors and spreadsheets. Then, package software began to take over organizational support functions like human resources, payroll, accounting, and niche functionality. Now, highly configurable cloud packages provide or supplement even core business functions in most companies; ranging from small functional packages to large enterprise software.

The context and scope of package software projects vary widely. Common package software projects include one or more of the following:

  • Upgrade: technical and/or functional
  • New implementation: out of the box, configuration, and/or customizing
  • Integration with other systems (in-house or vendor supported).

As packaged, third-party solutions become more common, BAs need to modify their traditional approach to meet the unique needs of package software projects.

I first started outlining these differences in my team practices and on my projects back in the late 90s. Since that time, I’ve seen a huge jump in the complexity of these implementations. While requirements analysis and implementation analysis for package software have not changed much, the risk of getting it wrong has increased dramatically.

The mindset that needs to change, not the techniques

The BA role remains the same for traditional projects and package software projects: protect and optimize stakeholder and organizational value. Many of the same techniques can be used, but the BA mindset and how it’s all documented and facilitated may change.

Worry about fit, gaps and change management

When working on package software projects, a fit/gap analysis mindset is crucial along with a keen focus on how the users world is changing and empathy for these changes.
BAs need to look at how the package “fits” the desired outcomes and processes, and identify gaps between the package functions and the current state functions. BAs should work with stakeholders to determine if gaps need to be “bridged”—can we operate within the package functions or do we need to adapt the process or technology to meet our needs?

WickJuly14 2

Documenting this fit/gap decision process is a key BA role, including facilitating options and alternatives to minimize the gaps. Even when implementing “out of box,” this process and analysis is critical to success. “Out of the box” typically means process or operational changes somewhere, BAs are in the role to identify where the changes will happen and prepare the users for these changes.

Don’t force the templates

Once BAs enter the fit/gap mindset, then they need to determine how to effectively document the package software project.

I often see BA teams struggle as they hold on tightly to their templates, trying to make them work for package software projects. Many typical templates don’t serve package software projects well. Typical templates assume a custom development approach, and forcing BAs to use these templates creates a lot of pain and challenges for package software projects.

So PLEASE, challenge traditional practices and templates when participating in package software projects. You still need requirements, but timing, and level of detail/abstraction must be appropriate.

Careful not to waste time on detailed documentation of your organization’s current state. The vendor usually has current state documentation for the package and this will become the future state in most cases. Focus on the future state and what must happen going forward, only looking back to the detailed current state when we need to identify details to carry forward. Also, it’s likely project sponsors purchased the package to gain efficiencies and change processes and business operation—they don’t want an exact replica of current state.

Instead, manage your work at a function level. Before selecting the package, what an actor wants to accomplish and rules are important. After selecting the package, the future state and “how” the actor accomplishes it becomes important as a change management piece for piloting, testing, training, and implementation.

We don’t want to document functionality already built. Exactly how it’s done in the package can be redundant to document when the vendor typically has this documented. So, avoid documenting requirements for package software that duplicates functional specs and design of software already built.

Don’t rely on the vendors BA 100% for the BA role

WickJuly14 3You need an internal BA (or BA team) to support a package software project. If you rely solely on the vendor BA, you will not successfully identify and bridge functionality gaps. The vendor BA understands the product, but does not fully understand your environment—your systems, processes, culture, politics, pain points, exception processing, integration issues, etc.

Both BAs—vendor and internal—are critical to success. The internal BA does not fully understand the product and needs the vendor BA to validate functionality and fill gaps.

Whether it’s two people or two hundred, the internal and vendor teams need to come together like puzzle to teach each other, build trust, and work through issues.

Upgrades need BAs

It’s quite common to hear teams say that package software upgrades don’t need BAs or requirements.

Challenge this assumption! Upgrades almost always have user impact or at least a risk of user impact. If users use the system, there are requirements!

Whether the change is minor or technical, a knowledgeable BA should be consulted. Even if the upgrade has been successful at several other sites, there is still a chance that your organization’s unique configuration or system integration could be negatively affected by the upgrade.

So ask requirement-resistant team members a few questions like: Why are we spending money on the upgrade? How do the users benefit? What would happen if it’s not done? Help them understand potential impacts and how BAs bring value to all projects.

WickJuly14 4A note about configuration

Most modern package software is highly configurable with hundreds of settings that impact software functionality.

If your project team has not worked with highly configurable software before, be prepared for a new layer of complexity throughout the project lifecycle.

  • BAs may need to consider configuration settings when writing business rules or detailed requirements.
  • Projects may require a separate phase of “configuration testing” and piloting the package.
  • BAs may need to educate testers about configuration settings and help them trouble shoot issues/bugs to determine if the errors are configuration errors or system bugs.

BAs will be supporting even more package software implementations in the future. If you haven’t experienced a package software project yet, you will soon—be ready.

Don’t forget to leave your comments below.

Doodle images above provided by Dan Wagner. Learn more about Dan’s doodle art by emailing him at [email protected]

7 Habits of Highly Effective Business Analysts

Written by Angela Wick on . Posted in Articles.

Highly effective BAs, regardless of their skill level or years of experience, consistently hone their craft. Guided by curiosity and passion, great BAs are always on the lookout for growth opportunities—ways to strengthen and sharpen their skills.

This focus on continuous professional improvement goes far beyond attending an annual conference or workshop. Instead, effective BAs develop daily habits that demonstrate leadership and expertise.

So, I’ll borrow Stephen Covey’s popular “seven habits” framework to discuss the recurrent behaviors that support excellence in the business analysis profession.

Although I refer to these as BA habits, they can be applied to most professions. So, whether you are a project manager, a tester, a techie or a trainer, think about how these habits can help you become a leader in your organization.

Habit #1: Effective BAs engage stakeholders.

BAs need information, cooperation and trust from their stakeholders. Skilled BAs get what they need by building strong relationships. They engage stakeholders in a way that inspires engagement, creativity, collaboration and innovation.

How do you know if your stakeholders are engaged? Well, these are common issues on teams with weak stakeholder engagement:

  • Strongly conflicting requirements between stakeholders.
  • Stakeholders are silent; roll their eyes, sigh or multi-task during meetings.
  • Stakeholders do not contribute to the project. They don’t return phone calls, do not reply to emails, do not review project documents, provide resources, etc.
  • Stakeholders show up late for meetings, leave meetings early or skip meetings.
  • Disparate groups do not understand other stakeholder’s needs and benefits from the project.
  • Progress is slow.
  • Discussions loop in circles.
  • Decisions are difficult to obtain.

Do you see any of those things happening consistently in your organization? Effective BAs use their influence to create an environment that looks more like this:

  • Stakeholders have a shared vision and can communicate the vision to their team/s.
  • Stakeholders understand their connection to each other.
  • Stakeholders trust each other and the BA.
  • Stakeholders enthusiastically participate in meetings.
  • Stakeholders make themselves and their resources available to the BA as needed.
  • Questions, discussion and meaningful debates.
  • Proactive, 2-way communication

Habit #2: Effective BAs research new techniques.

Great BAs love discovering new tools that make work efficient, valuable and maybe even fun. Experts estimate there are more than 500+ BA techniques in use today—literally lurking around every corner. Here are a few ways to find them:

  • Read the BABoK! The IIBA’s comprehensive handbook describes 40 of the most common and useful BA techniques. Current IIBA members can get a sneak peak at BABoK 3.0 by participating in the public review process. 
  • Attend industry conferences and workshops. Full-day or multi-day training sessions give BAs exposure to a variety of new techniques, trends, and methodologies. Many training companies and universities offer BA training. IIBA and PMI sponsor events across the world.
  • Network. Connect regularly with other BAs. Ask them about new techniques. Find out what works on their projects. Solicit advice when you hit road blocks.
  • Observe others. Find a mentor. Watch your peers. Which techniques do they use regularly? Are they working? Why or why not? How could you make them better?
  • Borrow from other industries and professions. The most obvious example may be the lean processes project teams have borrowed from manufacturing. Are there techniques you could borrow from an elementary school teacher, a farmer, a scientist or an actor? Definitely!

Habit #3: Effective BAs experiment with new techniques.

Now, it’s time to put those new techniques to work! Stagnation and boredom are the enemy of an effective BA. Applying new techniques keeps BAs motivated, engaged and inspired.

Experimentation often invites risk, but there are many ways to contain possible fallout:

  • Start small. Try a new techniques on small, low risk projects. Apply the new technique to a small part of a big project.
  • Break it down. Find a way to break the new technique in pieces. Try one piece on an analysis or elicitation effort to see if it is works. Then get feedback and adjust course if needed.
  • Find your friendlies. Use a new technique with a small, friendly group of co-workers. Encourage them to give you honest feedback.
  • Set expectations. Let stakeholders know why you are trying the new technique.
  • Ponder plan b. Courage to try new things includes the possibility of failure. Think about the worst case scenario. What’s your plan b if the new technique fails?

Habit #4: Effective BAs plan to re-plan.

I run into so many BAs that get stressed out by estimating requirement deliverables. They often ask, “How can I estimate when I don’t have any requirements yet?” My answer: “We plan to re-plan!”

As the project needs and scope evolve, effective BAs revisit their estimates—they reevaluate and adjust as the project moves forward.

Every BA leader and PM I have talked to about this agrees. It’s totally fine to change the estimate and re-plan, just not at the last hour!

So, set expectations and share them.

  • Make sure the PM and other leaders understand that this is your best estimate based on the current state of the project.
  • Help them understand which factors will increase or decrease estimates.
  • Plan resources: What can you do in the early stages of the project to anticipate estimate changes? Who can you pull in if you get behind? What tools can you use to be more efficient? How can you manage busy SMEs to get good requirements?
  • Look at the value and risk of scope items and adjust the plan accordingly to spend more time on high value and high risk items.
  • If your incentives are based on estimation accuracy, then talk to your leader about re-planning and how it fits in the incentive plan.

Effective BAs know that re-planning will be required to protect the project value. They look at the tasks and deliverables like puzzle pieces that need to be flipped, turned, and shuffled until they all come together in their proper place.

Habit #5: Effective BAs use visuals, often.

In most cases, visual communication is more effective than text-heavy documents or verbal descriptions—humans process visual information more quickly and completely. Effective BAs understand the importance and efficiency of visual communication. They always look for new and improved ways to use visuals in their meetings, presentations and documentation.

Skilled visual communicators:

  • Create high-level conceptual visuals, low-level detailed visuals and everything in between.
  • Tailor their visuals to meet the needs of their audience. Does a CEO want to review a 20-page process model? Does a group of SMEs want to focus on the whole organization or just their piece of the pie?
  • Draw spontaneously on white boards when discussions start spinning.
  • Use visuals in virtual meetings too. They use virtual whiteboards, post-it notes, flow charts, etc.
  • Know that visuals do not need to be perfect. You don’t need to be an artist. You don’t need 100% accuracy on day one. A flawed visual is so much better than starting with a blank page.

Habit #6: Effective BAs develop Underlying Competencies.

Obviously, BAs need techniques and tools to complete their practical tasks, but they also rely on underlying competencies. The techniques are like the tools in the tool box, but underlying competencies (UCs) influence how the tools are used and how the techniques are applied. UCs are the artistry, the finesse, or the soft skills.

Effective BAs continuously refine their UCs in many of the same ways they develop techniques: research, training, observation, experimentation, etc.

Effective BAs maintain dozens of UCs, but here are a few of the most important:

  • Critical thinking and Problem Solving
  • Teaching
  • Leadership and Influence
  • Facilitation and Negotiation
  • Personal integrity
  • Organizational Knowledge

Habit #7: Effective BAs consider politics.

Politics exist in every organization.

In project work, politics usually play out during prioritization efforts: which work will get funding, whose projects fit into an implementation, which requirements get cut.

Skilled BAs don’t ignore politics, but they avoid playing. They work around and within them.

How do effective BAs walk this fine political line? How do they understand and manage politics without getting involved? Good questions. Here are a few ideas:

  • Build wide support to eliminate politics as a factor.
  • Always redirect the team back to the project value. Which requirements, timelines, bug fixes, testing strategies, etc. best support the goals of the project and value to the organization?
  • Gather data. In many cases, good data can tell as story that transcends politics and makes the right answer obvious.
  • Lead with empathy. Understand what each stakeholder is seeing, hearing, thinking, feeling. Use these insights to help you influence each stakeholder.
  • Understand the definition of success for each stakeholder.

Which habits make you a highly effective project professional?

Don’t forget to leave your comments below.