The Business Analyst Coach Podcast Artwork

Why is Enterprise Analysis not the first knowledge area in the BABOK?

This is one of the most frequent questions I get from students attending the CBAP-CCBA prep courses. This is one of those concepts where the light bulb needs to go off if you have to place it correctly. We discuss this and a lot more about arguably the most controversial chapter in the BABOK.

In this podcast, we deep dive into Enterprise Analysis. It was a lot of fun to discuss this topic with Steve Downer, who is very enthused about this topic. I also got an opportunity to learn a few new things from his wide spectrum of experience.

Here is enterprise analysis (and much more) coming to life from the futuristic Steve Downer:

Click to continue

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

Can BABOK help your improve your business analysis practice? 

The Business Analyst Coach Podcast Artwork

Time and again, I have witnessed (and know first hand) that having knowledge about performing certain tasks can be useful. In this episode of I present an interview with Jarett Hailes on his certification journey and how it helped him improve his practice.
 In one of the previous BA interviews, Margaret Marco insisted that BAs should go independent after getting their CBAP, Jarett takes this notion further and elaborates on how getting certified can specifically help you. Listen to his inspiring journey of how BABOK changed his approach to analysis and helped him effectively implement business analysis best practices. 
Here is the interview:

Click to continue

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

I must admit, I have a love-hate relationship with templates. On the one hand they can be an effective way to support well-defined business analysis processes, ensuring deliverables are presented in a consistent manner and facilitate a shared vision. On the other hand they can be cumbersome, overly-complicated forms that lead to confusing, boring deliverables that detract from their original intent. As Business Analysts, what can we do to define and refine our templates so they help more than they hinder our goals?

When I’ve worked with clients to enhance their organizational business analysis maturity I’ve developed templates to support the business analysis processes being put in place. Through my work with these organizations, I have come up with some initial overall assessment and template-specific criteria to help figure out when a template is needed and if the developed template is ready for use.

Initial Overall Assessment Criteria

To get started, I usually want to determine which templates are needed versus what may be nice to have or even hamper business analysis activities. Some of the typical questions I will ask include:

  • Who performs the business analysis activities for the organization?
  • What is their level of expertise and competency in business analysis activities?
  • What are the deliverables within the business analysis function for the organization?
  • What tools are available to develop and maintain business analysis deliverables?
  • How will the content within the business analysis deliverables be used by stakeholders?
  • Are there related job functions within the organization that will contribute to a shared deliverable or where the business analysis output is already defined in one of their templates?
  • What is the size of the organization or organizational units in scope that will use the templates?
  • How diverse is the employee population (in terms of educational background, cultures, and job functions)?
  • What is the recent employee turnover rate for the organization?

For each deliverable a BA may expect to develop, you can use the above information to determine whether a template is mandatory, helpful but not absolutely necessary, or has limited value.

In smaller organizations or organizational unit (less than 200 people), I have found less need to have templates for intermediate or seldom-performed activities, particularly if they share a similar background or have been predominantly working together for many years with little turnover. In these situations staff can often quickly understand each other through a variety of communication methods, and are less reliant on standard documentation to achieve a shared vision. In some circumstances, the rigidity of a template can inhibit their dynamic communication or adds an unnecessary layer of work before they can continue to the next task in the process.

Organizations that rely on people to perform business analysis as a secondary job function, or who frequently bring in business analysis consultants or contractors to perform BA tasks, often benefit from having more templates than fewer ones.

Template Quality Criteria

A good template is like a good deliverable: it should be understandable to its target audience, be purpose-driven, and present a clear and consistent message. The University of Reading in the UK has a very good list of 16 quality criteria for any document, which can also apply to templates.

When a template is drafted, the following questions can be put to all the stakeholders involved in the creation and use of deliverables based on the template:

  • Is the purpose of the template clearly defined?
  • Is it easy to see when the template should be used, either in the business analysis process documentation or within the template itself?
  • Are there instructions on how to complete the template? Have they been vetted by the users of the template as being clear and relevant?
  • Are there examples on how to complete the template?
  • Are there related templates for diagrams or other artifacts that go into the template?
  • Is it clear which sections must be completed versus optional?
  • For optional sections, does it clearly state when these sections should be included?
  • If there are many optional sections:
    • Are there several either/or sections?
    • Are there sections for infrequent occurrences?
    • Would it be better to have separate templates for alternative circumstances?
    • Where there is information being pulled from other sources, is it clear how to bring that information into the template in a consistent manner?
    • After you’ve used the template a couple of times, do you find yourself having to spend more time customizing or removing information from the template than you do putting information into the template?

Once the template is developed, it should be reviewed regularly to ensure it still meets the needs of the organization given the inevitable changes that occur over time. The only thing worse than no standards is out-of-date standards.

Beyond Traditional Documents

As Business Analyst tools and techniques have matured, alternatives to traditional Office document deliverables are starting to become more prevalent. Whether you are using a wiki, a video, an interactive web-based presentation, a functional or non-functional prototype, or some other manifestation of business analysis work, the above principles for template development still apply. Some level of standardization with these outputs develops consistent stakeholder expectations and ensures the resulting outputs are able to be used in the next stage of the overall organizational process that business analysis is occurring within.

Templates can be a helpful addition to a BA’s toolkit or a hindrance to getting work done; if you are going to use them take the time to develop meaningful and actionable templates that will make your life simpler in the future.

Your Thoughts Please

 How has your experience been working with templates? Please use the comment area below to leave your feedback or any questions.

The Business Analyst Coach Podcast Artwork

  To Function or Non-to-Function? 

We all know the golden triangle of software requirements:
Business Requirements -> Stakeholder Requirements -> Functional Requirements.
Ensuring that the right business requirements are elicited and analyzed ensures that you are solving the right business need. Stakeholder requirements ensure that the stakeholder needs are identified and trace back to the business requirements. And finally, the Functional requirements bring forward the functionality that is expected of the glorious future state system. 
 
What about Non-Functional requirements? (I am not a big fan of the way they are referred to as) 
 
Why do they not get the limelight they deserve? How does one go about approaching them correctly? How do you ensure that you’ve asked all the right questions that help you elicit the pertinent Non-Functional requirements? 
 
In this episode of the AuthorCast, I am pleased to present Roxanne Miller a self-proclaimed requirements freak. Her extensive background in software development, training and consulting lead her to author one of the most sought after books on Non-Functional requirements – ‘The Quest for Software Requirements”. In this podcast we deep dive into some of the problems that plague the BA community when it comes to the specification and modeling of the Non-Functional requirements. 

Here is the episode:

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

 Wait a minute, did I just say that there is a template called “BA Approach”?
 
Chances are that you may already be involved in contributing to defining business analysis approach one way or another – without knowing it, now is the time to discover it! 
 
Like some of the tasks in the BABOK don’t directly align with what you do or it maybe called differently. One classical example is conducting a “Requirements gathering sessions” vs. what the BABOK refers to it as “Conducting Elicitation Session”… btw, I have a big issue with the word “gathering”, we will leave this one for another post another day!
 
So, back to “Business Analysis Approach” and understanding how you can perform it in your projects effectively. 
 
In this post, you will learn and understand what defining a BA approach really means and also learn how to use the BA Approach template.

First Principles – What is Business Analysis Approach?

Let me illustrate with an example. Imagine John and Mary are getting married. If this is a “Change” that needs to planned, a lot of things have to be done until the day of exchanging the vows. And imagine Julia is getting hired as an event planner responsible to organize and plan their wedding. She would have to:  
  • Clearly understand what values are dear to John and Mary as a couple
  • What kind of wedding they wish to have (low-key, high-profile, destination, etc.)
  • What kind of wedding invitations need to be printed
  • The complete guest list and detailed profiles of their family members and close relatives 
  • A VIP guest list 
  • Food preferences, menu choices, etc.
etc…. you can imagine other important components. 
 
If Julia was a BA in her previous life (and regrets switching to being an event planner), her approach to planning wedding will include:  
  • A checklist of tasks that need to be performed to make the wedding successful (checklists for different aspects)
  • A list of stakeholders that need to be invited or  consulted.
  • Deliverables and milestones to be achieved all along (sample wedding card, cake prototype, menu sampling, booking and tour of the convention centre, photography and videography, etc.) 
 
If you notice, she has externalized her intentions, ideas and work on paper. This helps her to do her job better, and calms the nerves of the couple-to-be. 
 
As a Business Analyst (especially if you are a seasoned professional), doing this at the beginning of your analysis can help you immensely perform your job better.

BA Approach In BABOK 

The first knowledge area in BABOK – Business Analysis Planning and Monitoring – elaborates on BA Approach (BABOK 2.1).  Here is a definition from BABOK (V2): 
 
“Business analysis approaches describe the overall process that will be followed to perform business analysis work on a given initiative, how and when tasks will be performed, the techniques that will be used, and the deliverables that should be produced.”

Three Secrets to a Great Start 

  1. Understand the problem and organizational context - understanding  the business problem being solved or looked into is an important first step. Your approach to build a software would be different from the one to outsource or improve a process. Is the organization process heavy and mature or is a start-up filled with instragramers who will post the product backlog on Facebook. 
  2. What type of project is it? – closely related to understanding the problem, take a step back and understand what kind of project is being undertaken. Is this an in-house software development for a mission critical business application or a COTS (Commercial Off-the-Shelf) product for a not so critical department. 
  3. Introspect and seek help right away if needed – do you have experience in working on a project like this before? If you do, don’t let your past experience cloud fresh possibilities. If you don’t have experience either in working on a similar project or using the current methodology, seek help from another BA / Requirements Manager or a Centre of Excellence if the organization has one. You don’t want to do 12 months of work and then appear foolish at the cost of appearing a fool for the first 12 hours.  

The BA Approach Template – Key Components

  1. Approach for BA Work – this section should describe at a high level what approach is being followed to perform business analysis. What crucial elements need to be part of approach. Providing an overview of the business problem, goals and objectives is useful. 
    1. Techniques, Deliverables, and Timeline is a key component here:
      -       Create a list of techniques such as process modeling, use cases, document analysis, requirements workshops, and interface analysis.
      -       Produce a high-level business requirements document and a detailed stakeholder and solution requirements document.
      -       Establish a high-level timeline of abstraction showing key business analysis milestones leading up to requirements sign off.
  2. Timing of BA Work - is the BA work going to be done in the beginning or performed iteratively all through the project. 
  3. Formality / Level of Details - depending on the organizational context a formal approach maybe adopted. If there are requirements standards that need to be followed, this needs to be detailed here. 
  4. Requirements Prioritization Approach - how will the requirements be prioritized and the key stakeholders involved in the requirements prioritization process.
  5. Tools for BA Work - if there are any requirements management tools or repositories used, this needs to be detailed out here.
  6. Project Complexity - this could be an assessment of how complex the project is based on the number of impacted areas and the criticality of the change from the organizational perspective.
  7. Approach to Scope and Change Management - how will the changes to scope and requirements be handled, if a high level process or flow chart needs to be built, you could define it here.
  8. Approach to Sign-off - what modality and approach will be followed to get concurrence and sign-off for requirements.
  9. Approach to Communication - how will the communication occur, the medium and frequency used.

Business Analysis Approach Template – Download for FREE

[Coming soon] 
 
We are putting together a great list of FREE templates for the BA community. The BA Approach template will be part of this and you will be able to download a FREE template soon.

Your Thoughts Please

Have you used a BA approach template or creating something analogous before you started analysis? What name does this template or activity have in your organization?
Page 3 of 2112345...1020...Last »