Tuesday, 16 October 2012 05:22

The Bad Ass BA: How Do You Know When Business Analysis is Being Done Well?

Written by Cecilie Hoffman and Rebecca Burgess

FEATUREOct15thA senior manager posed this question at the end of an all-hands meeting: “How do we know when business analysis is being done well?”

If you are a business analyst, it is easy to answer the question, “How do you know when business analysis is being done poorly?” While it is likely that what this senior manager wants is success criteria, there’s a useful intermediate step, which is to identify the symptoms of success. Let’s assume this manager is getting ready to make changes in his organization so that defining business needs and recommending solutions that deliver value to stakeholders enable the desired organizational change. Moreover, the activities leading to and following from the change will happen in a predictable, efficient and, dare we say it, a manner that makes people proud to be part of the organization? Yes, we dare.

Try the following exercise for yourself. Fill in the blank: “You know that business analysis is being done well when _______________________.” Here’s what we came up with. We have included the perspectives of many different organizational levels.

  • The business’s “vision” is expressed in terms of a vision statement and a roadmap for how it is going to get there. The roadmap is updated frequently to reflect the progress of development programs and projects, and changes to the business vision as the market changes.
  • Product management teams understand the difference between a vision, a roadmap, a portfolio and a project pipeline.
  • After the agony of elicitation, modeling and analysis, the answer/solution/approach is obvious to all stakeholders (and they agree on which one it is).
  • Successful approaches are repeatable and results are reproducible.
  • An organization’s ability to identify the success criteria for a proposed new program or project includes meaningful metrics.
  • The enterprise has the habit of building in baseline measurement and trend analysis.
  • There is no resistance to measuring/monitoring the effect of change.
  • Time to create quality documentation is protected; historical documentation is valued for potential re-use and for use as a reference.
  • Junior and mid-level business analysts can connect their tactical work to their organization’s strategic goals and the enterprise’s strategic goals.
  • Senior business analysts know what their business customer’s 5-year business roadmap is and how that roadmap is supported by IT’s 5-10 year technology roadmap.
  • New-hire business analysts are given ready-for-them-on-day-1 materials, organizational charts, process map repositories, and BA best practices/templates repositories.
  • HR, product managers, project managers and line (organizational) managers understand the difference between the following roles: business analyst, application analyst, quality assurance analyst, UI designer, database analyst, developer.
  • Entry-level new hires are not given the business analyst title until they have demonstrated some if not all of the fundamental skills of a business analyst. This common practice devalues the role of the business analyst.

“But wait,” you say, “there’s more!” You are right, there’s much more, but let’s press forward past the symptoms. Let’s take an organizational perspective. First, we need some context.

Here’s the conundrum that line managers of business analysts face: business partners/clients/customers want a business analysis service that provides both a strategic partner and a faster-than-light order-taker. Many BAs begin their professional lives in order-taker roles. Over time, they develop their skills and chance upon a situation where their insight, experience and knowledge enable them to contribute at the level of strategic partner.  After the head rush and deep sense of professional fulfillment from receiving the first “Your contribution as our strategic partner delivered results far beyond our expectations” comment, few business analysts will be content returning to the role of an order-taker. A good manager understands that the BA as strategic partner vs. order-taker isn’t an either/or question, but is a question of organizational maturity.

Regarding organizational maturity, we need to remember the late 1980s when Watts Humphrey first published his Capability Maturity Model (CMM) as a paper, then as a book, Managing the Software Process. The 1989 model defined five levels that were points on a continuum:

  1. Initial (chaotic, ad hoc, individual heroics) - the starting point for use of a new or undocumented repeat process.
  2. Repeatable - the process is at least documented sufficiently such that repeating the same steps may be attempted.
  3. Defined - the process is defined/confirmed as a standard business process, and decomposed to levels 0, 1 and 2 (the latter being work Instructions).
  4. Managed - the process is quantitatively managed in accordance with agreed-upon metrics.
  5. Optimizing - process management includes a deliberate process of optimization/improvement.

According to the Software Engineering Institute, which sponsored the development of the Capability Maturity Model, "Predictability, effectiveness, and control of an organization's software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief." That was the perception back in the late 1980s. Fast forward to 2012. We now have a variety of rapid iteration software development methodologies that have the intent of optimizing the software development process but, well, let’s be honest, are often misused to avoid doing the hard work up front of defining goals and success criteria.

As a result, we have this notion of “quick hits.” A quick hit is often a solution to a problem that everyone wants solved yesterday. Getting any form of relief to the problem is so urgently demanded that people adopt a just-get-it-done attitude and throw money at it. Quite often the quick hit is a short-term success, not because the effort in the spotlight and a few individuals’ careers are riding on a good outcome, but because the business analyst defined the problem so well that the solution’s objectives were highly constrained so that the requirements could be met with a minimum of design, which would mean that development was low risk so functionality could go into production like an arrow to the target.

While the quick hit model for projects delivers immediate gratification, anyone taking the long view realizes that the success of a quick hit is often counter-intuitive. Sure, the quick hit solution was speedy, and it met the letter of technical requirements but it isn’t extensible and it has few “-ilities,” namely, scalability, reliability, compatibility, manageability (four of the many “non-functional,” requirements for readers who aren’t business analysts).

Moreover, the more emphasis placed on quick hits, the less focus there is on strategic planning and understanding the big picture, that is, the business model and business architecture view of the business’s needs. People who are rewarded for putting out fires with quick hits are not receiving incentive for thinking about the long-term ramifications, nor do they feel at liberty to think strategically.

In 2010, Alexander and Osterwalder and Yves Pigneur published their handbook for visionaries, game changers, challengers and empowered business analysts called Business Model Generation. When there is no business model, an organization is low on the capability maturity model; development is chaotic, quick hits are the norm rather than the exception, and innovation is haphazard at best.

In 2011, Robert Strohmayer identified the business architect at the top of the list of the six hottest jobs in IT (“The 6 Hottest New Jobs in IT”, Infoworld, June 2011). Strohmayer quotes Alex Cullen, a VP at Forrester Research and the Research Director for Enterprise, Business, Application and Development and Technical Architectures, "Business architecture is about making sure the whole business holds together . . . it's a role built around business planning, pointing out opportunities to utilize IT more effectively." Simply put, business architecture model is a blueprint of the enterprise that provides a common understanding of the enterprise and is used to align strategic objectives and tactical demands.

When business analysis is being done well, the practice of creating and maintaining the business model and the business architecture is as deeply ingrained in the organizational practices as the tradition of the quarterly all-hands meeting. Not having the business model and the business architecture model as references would be unthinkable. After all, how will an organization know what it is doing and how things will affect it in the long term?

When business analysis is being done well, the organization values having the solution to a problem defined along the dimensions of the users, the interface, the capabilities that the users and the business will have, the data, the controls, the environment that the solution will deployed into, and the quality (those “-ilities”). If you want to know more about these seven dimensions, take a look at Discover to Deliver, just published by Ellen Gottesdiener and Mary Gorman.  Discover to Deliver articulates a methodology based on rapid iteration for ensuring that what gets built has long-term value and can be linked directly to an organization’s strategic goals.

When business analysis is being done well, business customers see their business analyst as a strategic partner, and they see an empowered business analyst who knows the business’s 5-year roadmap, not just their program portfolio, not just a project pipeline and not just the project in front of their nose. In our experience, business analysts who work in organizations that are not mature in the CMM sense are only as good as the managers who protect them. No business analyst who consistently takes initiative, challenges the conventional perspective, raises uncomfortable issues and brings transformational (disruptive) ideas to the table will survive without at least one manager watching their back and providing them with information about the political climate and budget sensitivities.

When business analysis is being done well, executives see the product managers as entrepreneurs, the enterprise architects as intrapreneurs, and everyone sees senior business analysts as brilliant strategic partners.

Don't forget to leave your comments below.


Cecilie Hoffman's professional passion is to educate technical and business teams about the role of the business analyst, and to empower business analysts themselves with tools, methods, strategies and confidence. She works for a Fortune 100 company that is asking the right questions. Cecilie.Hoffman@comcast.net.

Rebecca Burgess is a certified Six Sigma Black Belt and a business process analyst at Academy of Art University in San Francisco, California. After many years of uncovering problems and determining root causes, she is now applying her BA skills to strategic process design and improvement.  Rebecca_Burgess@Yahoo.com

Read 20020 times

© BA Times.com 2019

macgregor logo white web