Tag: Career

The Adaptive Business Analyst – As Complexity Increases, the BA Adapts

Written by Kathleen B. Hass, PMP on March 5, 2012. Posted in Articles. 1 Comment on The Adaptive Business Analyst – As Complexity Increases, the BA Adapts

The world, she is a’changin’. The Internet has made everyone on the globe hyper-connected and has transformed virtually all industries: publishing, broadcasting, communications, and manufacturing. Did you know that just a few short years ago:

Facebook	Didn’t exist
Twitter	Was a sound
LinkedIn	Was a prison
A Cloud	Was in the sky
An Application	Was something you used to get into college
4G	Was a parking space
Skype	Was a typo [1]

Fast forward to now. Traditional work has been commoditized. Anyone with an idea and a little moxie can use their laptop to set in motion a virtual new entity. You can go to:

Taiwan	For product design
Alibaba in China	For low-cost manufacturing
Amazon.com	For delivery and fulfillment
Craigs List	To do your accounting
Freelance.com	To do your logo [2]

If this isn’t bad enough, the heart and soul of middle class jobs are disappearing in the U.S. Consider this: When Apple began manufacturing the iPhone, the company estimated that it would take nine months to find 8,700 qualified industrial engineers in the U.S. to oversee and guide the 200,000 assembly-line workers eventually involved in manufacturing iPhones. In China, it took 15 days. [3] Result: we lost 200,000 iPhone manufacturing jobs.

Many believe that these and many other traditional jobs are not coming back to the U.S. So, what are the jobs of the future? We probably don’t even know what to call them, but they will definitely require creativity, innovation, invention, and lots of complexity. Even today, many companies in Silicon Valley do quarterly reviews of their key project leaders because they can’t wait to find out they have a poor BA or PM. Many U.S. companies report they can’t find the employees they need. American businesses also report that U.S. workers that are available are too expensive and too poorly educated as compared to workers in India, China, South Korea and many other countries.

What does all this Mean to the Business Analyst?

Employers are looking for critical thinking and an ability to adapt, invent, and reinvent; collaborate, create, and innovate; and an ability to leverage complexity to compete. Standout companies are using projects as the hotbed of creativity – so that means BAs and PMs have to step up their game. According to the 2011 CHAOS Report from The Standish Group, only 37% of projects delivered on time, on budget, with required features and functions.

The Cause: Gaps in enterprise business analysis and complexity management
The Cost: USD 1.22 trillion/year in the US and USD 500 billion/month worldwide in IT project waste
The Opportunity Cost: “If we could solve the problem of IT failure, the US could increase GDP by USD 1 trillion/yr.” according to Roger Sessions, a recognized expert in enterprise architecture and author of Simple Architectures for Complex Enterprises.

We need to fundamentally change the way we do projects so that 80% of projects are on time, budget and scope (see Figure 1). But we also need to focus on innovative solutions, not incremental changes to business as usual. And we need to bring about value to the customer and wealth to the organization – otherwise, why are we investing in the project? This is where the BA comes in – constantly focusing on value and leveraging complexity to foster creativity.

Figure 1: New Project Approach

Does the business analyst role change, either significantly or subtly, with highly complex projects? If so, how? Our framework for dealing with complex projects consists of four distinct activities (see Figure 2):

Diagnose Project Complexity
Assign Competent Leaders
Select the appropriate project management approach
Manage complexity dimensions

This article in the series will examine steps 1 – 3.

Figure 2: Project Complexity Framework

Step #1: Diagnose Project Complexity
The first step in understanding the level of complexity of your project is to assess each complexity dimension. Use the Project Complexity Model depicted in Figure 3. Facilitate your project team leads to agreement on which cells most closely describe your project for each complexity dimension. Then apply the project complexity formula to determine the complexity profile of your project. In my experience, the actual complexity of projects exceeds the team’s initial assessment prior to applying the model.

PROJECT COMPLEXITY MODEL 2.0

Figure 3: Project Complexity Model 2.0
© Kathleen B. Hass and Associates, Inc.

Then apply the formula below, Figure 4 to diagnose the complexity level of your project.

PROJECT COMPLEXITY FORMULA

Figure 4: Project Complexity Formula
© Kathleen B. Hass and Associates, Inc.

Step #2: Assign Competent Project Leaders
Complex projects require seasoned leaders, and the use of a shared leadership model (see Figure 5). The core project leadership team consists of the PM, BA, Chief Architect, Development Lead and a Business Visionary, each taking the lead when a particular expertise is needed.

Figure 5: Shared Leadership Model

Once the project complexity is known, it is imperative that appropriately skilled and experienced individuals are assigned to key leadership positions. Obviously, BAs need more sophisticated skills as they move from low complexity projects, to enterprise, strategic and innovation projects. The first order of business is for the organization to understand their BA Workforce. Check out the blog site: http://baassessmentmatters.blogspot.com/ posting on March 5^th entitled “Calling All BA Practice Leads!” It discusses how BA Practice Leads ensure their organizations have an appropriately skilled BA workforce (see Figure 6) possessing the capabilities needed to successfully deliver complex new business solutions that meet 21^st century business needs.

Figure 6: BA Workforce Capability Model

The BA Manager or Practice Lead then assigns BAs (and working with other managers, assigns other project leaders) based on the complexity profile of the project at hand (Figure 7). If the project leads’ capabilities are lower than the complexity of the project requires, it is almost certain that you will have a challenged and/or failed project.

Figure 7: Make Appropriate Leadership Assignments

Step #3: Select the Project Approach
As projects have become more complex, project cycles have evolved. Project cycles models are not interchangeable; one size does not fit all. Project cycles can be categorized into three broad types:

Linear: used when the business problem, opportunity, and solution are clear, no major changes are expected, and the effort is considered to be routine. A linear cycle is typically used for maintenance, enhancement, and continuous process improvement projects. It is also used for development projects when requirements are well understood and stable, as in shrink-wrap software development projects.
Adaptive: used when the business problem, opportunity, and solution are unclear and the schedule is aggressive. An adaptive cycle is typically used for new technology development, new product development, or complex business transformation projects.
Extreme: used when the business objectives are unclear or the solution is undefined. An extreme cycle is typically used for research and development, new technology, and innovation projects. [4]

Figure 8 shows the differences between linear and more adaptive methods.

Linear Methods	Adaptive Methods
Industrial-age thinking Plan based Distinct life cycle phases Tasks completed in orderly sequence Assumes predictability Lays out development steps Stresses the importance of requirements	Only firm basic requirements that are not expected to change (aka high-level requirements) and a release plan up front Many rapid planning and development cycles Produces small batches of tailored products on a tight schedule Evolution of requirements with each planning and development cycle Constant evaluation of the evolving product Constant evaluation of the value of functions in backlog

Figure 8: Linear vs. Adaptive Methods

As we move along the complexity continuum from independent, low complexity predictable projects to highly complex projects with lots of uncertainty, we also move along the spectrum of project cycle types. A linear approach works for a simple, straightforward project; whereas, adaptive, and extreme approaches are used to manage the uncertainties of increasingly complex efforts (see Figure 9).

Figure 9: Project Complexity Mapped to Project Cycle Approaches
© Kathleen B. Hass and Associates, Inc.

Low-Complexity Projects: Traditional Waterfall Methods
The traditional role of the business analyst does not need to change much to successfully execute activities on low-complexity projects. The linear Waterfall Model is appropriate (see Figure 10). However, to optimize the business analyst role, it is wise to adopt some of the principles of agile and iterative development for even low-complexity endeavors:

Prototype for requirements understanding, to reduce risk, and to prove a concept
Involve the business and keep the business analyst as a member of the core project leadership team throughout the project
Continuously validate, evolve, and improve requirements throughout the project.

Figure 10: The Waterfall Model

Moderately Complex Projects: Agile Methods
There’s no question about it: agile methods expedite the product development process, especially for products that are software intensive. Agile is an adaptive, streamlined model, based on having only essential people work in tight-knit teams for quick and efficient results (see Figure 11). As we’ve seen, one very important member of the team is the business analyst; if companies hope to achieve strategic goals, they need someone who is focused on the business value expected from the project outcomes. The business analyst provides guidance before funds are invested, during a project, and after the solution is delivered. She continually focuses on the evolving business requirements and serves as the steward of the business benefits. [5]

Figure 11: The Agile Model

Through leadership and collaboration, the project manager and business analyst guide the agile team, ensuring that it is both efficiently and effectively run and that it adds significant long-term benefits for the company with each iteration. The business analyst plays close attention to the original business case, recommending the project be terminated when the ROI has been realized.

Firm Basic Requirements
A business analyst’s main priority when she is first attached to a specific project is to elicit firm, basic business requirements (what we used to call high-level requirements, which outline the breadth of requirements and which we do not expect to change), to collaboratively determine the most feasible solution, and then to categorize releases into valuable features and functions. Then each release is initially described in enough detail to determine its cost versus its benefits, thus developing an ROI for each release.

Knowing what it will take to deliver each individual component of the solution as well as what the return will be to the organization, the development team can then build components or features based on business value, delivering the highest-value features first. As the project moves through the release schedule, the business analyst elaborates the requirements in enough detail to meet the development team’s needs for each release.

An Eye on the Business Value
As an agile project progresses through its life cycle, the team continually learns new information. It becomes clearer how many resources will be needed to perform detailed design, construction, and tests for each release, how much risk there is to the project, and how the risk needs to be managed. Accordingly, it is important to go back and check original assumptions about business value and costs to develop and operate the new solution to see if they are still true, or if the original business case has been compromised.

Validation after Every Release
By being involved during the development process, business analysts can validate that new components are actually meeting business needs and that the business case is still sound. They also take information to other groups outside of the agile team to further corroborate that the inevitable changes have the support of other stakeholders.

Organizational Transition Requirements
The operational environment needs to be analyzed and assessed before the solution components are implemented. Perhaps there will be a need for reorganization, retooling, retraining, or acquisition of new staff. Working with management, the business analyst helps to ensure the organization is prepared for the impact of the changes and can support the release plan. That way, when the complete solution is delivered, it can be operated efficiently and effectively.

Lighter Requirements
Agile requirements are typically “lighter” than those developed for linear project models. Requirements are visually documented whenever possible. The wise business analyst uses modeling to manage complexity. Less formal user stories (a high-level description of solution behavior) may suffice, as opposed to use cases.

Advanced Skills
Advanced skill development is required for business analysts who are working on agile projects. They need to develop new or higher-level leadership skills, including expert facilitation, coaching, collaborative decision-making, and team development. The analyst also needs to have a good understanding of software architecture and be proficient in decoupling the breadth of the solution from the depth of the solution into feature-driven requirements.

Highly Complex Projects, Programs, and Megaprojects: Extreme Methods
Welcome a certain amount of complexity and churn because it creates a chemical reaction that jars creative thinking,
—Colleen Young, VP and distinguished analyst and IT adviser, Gartner, Inc.

Highly complex projects offer the greatest opportunities for creativity: complexity breeds creativity. But the business analyst must understand the nature of complexity to leverage complexity to foster innovation. Complexity is one of those words that is difficult to define. Some say complexity is the opposite of simplicity; others say complicated is the opposite of simple, while complex is the opposite of independent.

Since complex projects are by their very nature unpredictable, it is imperative that the project team keep its options open as long as possible, building those options into the project approach. This approach requires that considerable time be dedicated to researching and studying the business problem or opportunity; conducting competitive, technological, and benchmark studies; defining dependencies and interrelationships; and identifying potential options to meet the business need or solve the business problem. In addition, the team experiments with alternative solutions and analyzes the economic, technical, operational, cultural, and legal feasibility of each option until it becomes clear which solution option has the highest probability of success. When the opportunity is unclear and the solution is unknown, traditional linear approaches simply will not work.

Last-Responsible-Moment Design Decisions
On highly complex projects, it is important to separate design from construction. The key is to use expert resources and allow them to spend enough time experimenting before they make design decisions; the construction activities will thereby become much more predictable. Linear methods might then be appropriate during the construction phase of the project.

Models for adaptive project management are still emerging. We suggest two that are designed to provide iterative learning experiences, adapt and evolve as more is learned, allow analysis and experimentation to determine solution design viability, and delay decision-making as long as possible (that is, until the last responsible moment, the point at which further delays will put the project at risk): the adaptive evolutionary prototyping model and the eXtreme project management model. There are significant differences between the adaptive and eXtreme approaches (see Figure 12).

Adaptive Methods	eXtreme Methods
Many rapid planning and development cycles Produce small batches of tailored products on a tight schedule Constant evaluation of evolving product Constant evaluation of the value of functions in backlog	Keep your options open Build options into the approach Discover, experiment, create, innovate Analyze problem/opportunity Conduct competitive, technical, and benchmark studies Brainstorm to identify all possible solutions Analyze feasibility of each option Design and test multiple solutions

Figure 12: Adaptive vs. Extreme Methods

Evolutionary Prototyping Model
The keep-our-options-open approach often involves rapid prototyping—a fast build of a solution component to prove that an idea is feasible—which is typically used for high-risk components, requirements understanding, or proof of a concept.

Evolutionary prototyping is quite effective for multiple iterations of requirements elicitation, analysis, and solution design. Iteration is the best defense against uncertainty because with each iteration, the technical and business experts examine the prototype and glean more information and certainty about functions that are built into the next iteration.

The strength of prototyping is that customers work closely with the project team, providing feedback on each iteration (see Figure 13). If requirements are unclear and highly volatile, prototyping helps bring the business need into view.

Figure 13: Adaptive Evolutionary Prototype Model
© Kathleen B. Hass and Associates, Inc.

eXtreme Project Management Model
An extreme project is a complex, high-speed, self-correcting venture during which people interact in search of a desirable result under conditions of high uncertainty, high change, and high stress. —Doug DeCarlo, author and lecturer, Extreme Project Management

eXtreme project management is sometimes also called radical project management. Some equate it to scaled-up agile methods. The approach consists of a number of short, experimental iterations designed to determine project goals and identify the most viable solution. As in the agile model, eXtreme project management requires that the customer be involved every step of the way until the solution emerges—a practice that involves many iterations. Like the iterative Spiral Model, the eXtreme model terminates after the solution is found (or when the sponsor is unwilling to fund any more research); the project team then transitions to one of the other appropriate models. One variation of the eXtreme Model spends a considerable amount of time in discovery, then prototypes, then transitions to modular development (see Figure 14).

Figure 14: eXtreme Model
© Kathleen B. Hass and Associates, Inc.

Challenges will arise at every turn, because it can be difficult to:

Know how long to keep your options open
Build options into the approach without undue cost and time
Gather the right group of experts to discover, experiment, create, innovate, and:
- Analyze the problem/opportunity
- Conduct competitive, technical, and benchmark studies
- Brainstorm to identify all possible solutions
- Analyze the feasibility of each option
- Design and test multiple solutions.

Operating on the Edge of Chaos
Conventional business analysis practices that assume a stable and predictable environment encourage us to develop all the requirements up front, get them approved, and then fiercely control changes. As we have seen, conventional linear project cycles work well and should be used for predictable, repeatable projects; however, this approach has proven to be no match for chaotic 21^st-century projects. Figure 15 compares the characteristics of projects on which conventional linear practices can be successfully used with the characteristics of projects that require a more adaptive model. A blend of the linear, adaptive, and eXtreme models is almost always the answer. The trick is to know when and how to apply which approach.

Conventional linear approaches work well for projects that…	Adaptive approaches work well for projects that…
Are structured, orderly, disciplined	Are spontaneous, disorganized
Rely heavily on plans	Evolve as more information is known
Are predictable, well defined, repeatable	Are surprising, ambiguous, unique, unstable, innovative, creative
Are built in an unwavering environment	Are built in a volatile and chaotic environment
Use proven technologies	Use unproven technologies
Have a realistic schedule	Have an aggressive schedule; there is an urgent need

Figure 15: Conventional vs. Adaptive Approaches

What exactly does it mean to operate on the edge of chaos? Complex systems fluctuate between a static state of equilibrium and an adaptive state of chaos. If a system remains static, it will eventually result in paralysis and death. Whereas, if a complex system is in chaos, it is unable to function. So, here is the genius of complexity: it breeds and nourishes creativity, as complex systems adapt to changes in the environment for survival. Complexity scientists tell us that the most creative and productive state is at the edge of chaos. (Refer to figure 16.) Therefore, complex project teams must operate at the edge of chaos for a time in order to allow the creative process to flourish. The business analyst assigned to a complex project must use adaptive business analysis methods to foster an environment where creativity is possible. The next article in this series explores the business analyst as creative leader of complex projects who are living on the edge.

Figure 16: The Edge of Chaos: the Most Creative State

Putting It All Together: What Does This Mean to the Business Analyst?
A business analyst who is an asset to highly complex projects is comfortable with lots of uncertainty and ambiguity in the early stages of a project. She leads and directs plenty of sessions of brainstorming, alternative analysis, experimentation, prototyping, out-of-the-box thinking, and trial and error, and encourages the team to keep options open until they have identified an innovative solution that will allow the organization to leap ahead of the competition. The BA who does not embrace complexity does so at her own peril.

Kitty is the president of her consulting practice specializing in enterprise business analysis, complex project management, and strategy execution. She is a prominent presenter at industry conferences, author and facilitator. Her BA Assessment Practice is the gold standard in the industry. KHass BA Assessments:

Appraise both BA organizational maturity and individual/workforce BA capability based on four-stage reference models
Present results that are continuously examined for reliability and validity by Lori Lindbergh, PhD, Senior Researcher and Psychometrician , Lorius, llc
Benchmark results against a global data base of BAs performing comparable work
Align with the IIBA BABOK^® and the BA Competency Model^®
Align with standards and best practices for quality and fairness in educational and psychological assessment
Are based on the skills and knowledge needed to work successfully on the complexity of current project assignments
Examine critical relationships between competency, project complexity, and project outcomes.

Don’t forget to leave your comments below.

[1] Tom Friedman, Michael Mandelbaum, That Used to be us: How America Fell Behind in the World it Invented and How we can Come Back, 2011.
[2] Ibid., p. 134.
[3] How the U.S. Lost Out on iPhone Work, The New York Times, January 21, 2012. Online at: http://www.nytimes.com/2012/01/22/business/apple-america-and-a-squeezed-middle-class.html?pagewanted=4&ref=charlesduhigg
[4] Robert K. Wysocki, Effective Project Management: Traditional, Adaptive, Extreme, 4^th ed. (Indianapolis: Wiley Publishing, Inc., 2007), 48.
[5] Kathleen B. Hass, “An Eye for Value: What the Business Analyst Brings to the Agile Team,” Project Management World Today (June 2007), 1-5.

The One Question to Ask a Business Analyst Candidate

Written by Kupe Kupersmith on December 13, 2011. Posted in Articles. 1 Comment on The One Question to Ask a Business Analyst Candidate

One of the hardest things to do in the business analysis profession is find the right candidate for the right job. It is no mystery that in spite of how far we have come, no two business analysis jobs are alike. Recruiters and hiring managers seem to be able to get a sense of a business analyst’s hard skills. They can review their resume and ask direct questions regarding the knowledge and experience with techniques like use cases, user stories, context diagrams, etc. They can quiz them on the types of projects they have worked on and the different methodologies from waterfall to agile and everything in between. I know many companies that have BA candidates present requirements deliverables and have them perform some BA tasks as part of the interview process.

Even with a case study interview process, it is still difficult to get a sense of a candidate’s analytical thinking ability. Although it is difficult to determine in an interview, it is one of the skills that separate good BAs from the great BAs. I’m talking about the ones with the ability to think abstractly, then break down an abstract challenge or opportunity and turn it into a solution. In 2011, most companies can find people with the hard skills. The accepted practices used at many companies have been around long enough, so finding people with the necessary hard-skill experience is easy. What the BA does with the information elicited is the difficult part to judge. How do you know candidate one can help your team better analyze a situation than candidate two? I have the answer. You need to see how well the candidate can guess.

In a recent Time magazine article, Good Guess, Why we shouldn’t underestimate the value of estimating, the author Annie Murphy Paul made me realize I had a valid reason to make candidates take a guess during an interview. The premise of the article is that estimation is the foundation for more analytical thinking and crucial for people searching for jobs in the knowledge-based economy in which we are in.

With the ability to “just Google it,” many people, young and old, no longer take a guess or rarely estimate because many answers are at their fingertips. By not practicing with estimation, you start to lose the ability to think abstractly. In some ways, Google makes us more efficient, while in other ways it makes us lose the necessary skill to be an excellent BA.

Here is a question I ask to see how well a BA candidate can guess. How much revenue per day is made by the Georgia State Road and Tollway Authority from cars passing through the Georgia 400 toll plaza? Depending on the answer, I can gauge an individual’s ability to think abstractly and analytically. If a candidate replies with, “Hold on, let me Google it,” I am not impressed. If they take a guess that goes something like, “There are almost 5 million people in the Atlanta area and half the people are adults. Of adults that can drive, 1.5 million own cars. Of the 1.5 million, a third probably live and work in an area that would require them to go through the toll. Of that .5 million, I’ll guess half or 250,000 go through the toll each day. The toll cost per day is $1.00, so they make $250,000 per day.” The actual answer after Googling it is closer to $60,000 per day, but who cares? What you should love about that answer is the thought process.

If you want to see if your BA candidates have the ability to think critically, keep them guessing. What great questions do you ask to determine which candidate to hire? Please share with the group below in the comments.

Abstractly yours,

Kupe

Don’t forget to leave your comments below.

The Big BA Picture; A Landscape Without Limits

Written by Mindy Duvernet on November 21, 2011. Posted in Articles. 1 Comment on The Big BA Picture; A Landscape Without Limits

Over the last thirty years the role of the business analyst has become more and more important. While the Project Manager ensures progress, it is the analyst that has been hired to assist with the necessary thinking on behalf of management. Managers have plenty to think about regarding all the projects and goals that affect the business bottom line and their customers. The primary focus of the analyst is to know the business processes and identify possible improvements.

The fact is that while the PMI (Project Management Institute) was founded in 1969 and has more than half a million members worldwide, spanning 185 countries, the IIBA (International Institute of Business Analysis) was established in 2003 and has about 22,000 members worldwide, with chapters in Africa, Asia/Pacific, Canada, Europe/Middle East, Latin American, Caribbean, and the United States. The comparison is telling as the role of the analyst has evolved out of the overwhelming amount of work the Project Manager saw as critical to project success. For the role of the Project Manager is centralized around managing time, budget, and scope. The role of the Business Analyst fills the organization’s need to know and identify goals, objectives, value-adds and measurements for the success of their projects.

The Business Analyst landscape is populated with every kind of business analyst you can imagine. There are:

Business Systems Analysts
Financial Analysts
Enterprise Analysts
IT Coordinator Analysts
Security Analysts
Technical Analysts
Research Analysts
And more

Each industry has its own flavor of analyst. Plus, every company has its own culture with variations of the usual artifacts that their analysts are hired to produce. The uniqueness does not stop there, as every civilization in the world has its own language. As some of us have observed, the non-verbal communication of shaking the head to indicate “Yes” or “No” means one thing in the United States and something else in India.

The entire landscape of analysts is very board. It stretches the breadth of the list of worldwide industries. There is Accidental & Health Insurance, Advertising Agencies, Aerospace/Defense, Agricultural, Air Delivery and Freight Services, Asset Management, Auto Manufacturing and Parts, and that is just the As. Other industries include Biotechology, Broadcasting (TV and Radio), Construction, Computers, Electronics, Energy, Fashion, Finance, Government, Hotel, Internet, Investment, Law Enforcement, Legal, Marketing, Medical, Music, Natural Metals & Materials, Oil & Gas, Pharmaceuticals, Publishing, Research, Retail (Food, Clothes, Toys, Furniture, Appliances), Services, Software, Sports, Wholesale, Wireless, and more. Of all of these industries the three highest profits earners are Money Centers and Banks, Drug Manufacturers, and Oil and Gas industries.

For financial management companies, like Amerprise, there are analysts on both the business side and on the technology side. Like all analysts, these thinkers leverage the organization’s methodologies and frameworks to determine what to utilize in creating the necessary deliverables. It is through thoughtful communication with the project stakeholders that an approach is formed to set the groundwork for accomplishing the results. Alignment with business processes, policies, and procedures is the analyst’s primary concern in the beginning stages of any project.

The next step requires that the analyst talk to all the subject matter experts about goals and objectives. If there is an IT aspect, there would be an analyst from the IT side to discuss automation opportunities based on their knowledge of the software and the technical experts who maintain the systems. The functional solution requirements then begin to take shape as these conversations occur and more information is evoked from the business-side stakeholders. The BA works to identify these IT capabilities and software/web functionality aspects to ensure a common understanding and set expectations.

Independent of organization or culture there is the expectation that the analyst knows the best ways to evoke the value-adds and basic benefits a project will create. Whether that analyst is strictly on the business side and has no interaction with technology, or whether they are a hybrid and have ideas related to technology, these competency distinctions are important to recognize. As many times the problems an analyst often walks into is the result of a business owner purchasing a software package for millions of users without first of all talking to the technology leaders who know their systems.

Recognizing these competencies are key to project success and that is why every team goes through a discussion about roles. On large projects a clear division of who is a business resource analyst and who is the technology resource analyst can help to clarify who has that expert knowledge. These roles are very important to ensure project progress and management when it comes to making decisions.

In this day and age, every company is on the Internet. Internet companies are largely about supply and demand, whether it is “Business to Business”, or “Business to Consumer” these companies employ analysts. Some are Inventory Analysts, others are E-Commerce Analysts, and then there are the Web Analysts that track the Internet activity based on “hits” from endless marketing and advertising efforts. In the Sports industry there is even a new job description known as a Player Analyst; an analyst that looks at athletic statistics of many talented athletes and creates teams based on the players strengths.

Regardless of which side the Business Analyst resides on, both sides are in a continual dialogue about process improvements and new ideas for creating value for their customers. These new ideas then have to be analyzed as part of a business case and then further defined to determine the size of the investment and the risks involved.

Sometimes analysts are instrumental in creating the business case. But, sometimes the analyst is engaged midway on a project or even after the first attempt has failed. If the idea is deemed feasible and the proof-of-concept portrays how the concept will satisfy more customers, which in turn shows the value that will grow the business, then the team is half way there.

The Bad Ass BA: “Business Architect”?

Written by Cecilie Hoffman on November 1, 2011. Posted in Articles.

What the heck is a Business Architect?

I have had the title Business Architect for almost a year now — I’m loving it. With about thirty years’ working experience in software and the last ten years in the role of business analyst, the next step for me was business architecture, but if you asked me a year ago what that meant, I wouldn’t have been able to give you a succinct answer, or tell you the elements of the discipline. It was something about the connotations of the word “architecture” that attracted me. The notion of integrating all the functionality together, having hierarchies of taxonomies in your head, ooh, ooh! But thinking and doing take more than a little effort to link. Sometimes stubborn people like me need a kick in the rear from the universe to get moving. So while I didn’t like getting laid off last year, because as much as I was relieved to be out of there, my pride was hurt, it was time to go and it forced me to recalibrate myself professionally and make the leap.

The trouble was, there was so much conflicting information about the role of the Business Architect. There’s lots of conflicting opinions on the differences in focus between an Enterprise Architect, a Business Architect, an Information Architect and a Process Architect.

Being intuitive and somewhat reckless, when the interview question came up from the Enterprise Architects about what technologies I would recommend, I heard these words coming out of my mouth, “Gentlemen, you shouldn’t be hiring a business architect to advise you on technologies. I may have my opinions, but there are far better qualified people out there for that. I would be bringing you information about business needs and business processes, not on technologies or solutions.” This was a phone screening. There was dead silence on their end of the line. Darn it, Cecilie, you’ve stuck your foot in your mouth again, I thought to myself. Then, I hear, “Okay! Would you tell us about a situation in which…” Whew, they were still talking to me.

I knew I could do the tasks identified in the job description, but I knew I had to get ahead of the professional development curve if I was going to succeed in this role in the long term. After a few months on the job, there was an opportunity to take the equivalent of Business Architecture 101 at a conference, so I signed up for two 1-day seminars. One of the seminars was just okay. The second one was mind blowing — one of those experiences where every synapse in your brain is pulsating and your neural matter hurts for days afterwards because new neural pathways are forming, and old, deep patterns that have never been challenged before have been cauterized out. I walked around for a week after that seminar like a grinning fool.

I needed definitions and I got ‘em. After keeping these definitions in the back of my mind for the past six months, I’m ready to share — they are valid and I hope you find them useful for your career development and for your endeavors in the Enterprise Analysis knowledge area of the Business Analysis Body of Knowledge.

What is Business Architecture?

First, a business architecture is not a business function/process model. Most business process models show an inventory of processes, but not an integrated model of the information used by those processes. Most business function/process models do not show the customer/consumer/end user or how that customer perceives the touch-points between the business processes and functions.

Business Architecture occurs when you integrate two or three or more different core cross-functional business processes in an engineering type of model, and as a result, make things more clean and efficient. This model is the beginning of an enterprise business architecture. The definition I use is a model of an enterprise (single company or industry) that shows the integration points of all the information that enables the enterprise to function. The model shows information sources, destinations and transformations.

Furthermore, for a single company, a business architecture is just one element of an integrated enterprise architecture. The integrated enterprise architecture includes business, technology, security and organizational architectural components to create a complete model. In addition to all the modeling techniques I have used as a business analyst, I have added capabilities, value streams and value chains to my bag of modeling techniques.

No discipline is without its controversies and the usefulness of basing an architecture on capabilities is one of those controversies. Here’s a definition of capability: the ability of an organization to use its assets to accomplish an activity that delivers business value or competitive value. I have memorized that phrase and can spout in out in my sleep. I can’t build a model of a capability that would stand up to a spring rain. Still, I see long threads on the business architecture discussion sites focused on how best to model “our unique ability to do ”. When the focus shifts solely to a linear process without a view of the integration points, I get worried.

A value stream is an end-to-end collection of activities that creates a result for a customer. The value stream has a clear goal: to satisfy or to delight the customer. “Delighting the customer” is a well-known phrase that comes to us from the Six Sigma and Lean Manufacturing disciplines.

Some examples of strategic visioning value streams are “insight to strategy,” “vision to eBusiness enterprise,” “concept to development,” “initiative to results,” and “relationship to partnership.” At Railinc, because the business architecture function is new, one of the first things my team had to do was define an “initiative to results” value stream and integrate it with the product management team activities.

You may be familiar with some customer-centric value streams such as “prospect to customer,” “lead to cash,” manufacturing to distribution,” and “request to service.” Business analysts are also typically deeply involved with business-enabling value streams such as, “forecast to plan,” “requisition to payables,” “resource availability to consumption,” “acquisition to obsolescence,” and “financial close to reporting.” People caring is another category of value streams, “recruitment to retirement” (less politically correctly known as “hire to fire”) and “awareness to prevention.”

I’ll go into value chains in a future article, but for now I just want to say that value chains are part of what a business architect builds. A value chain is a sequence of activities followed by a company in a specific industry. The chain of activities gives the product more added value than the sum of the independent activity’s value. As a simple example, take a master chocolatier as a profession. Cocoa mass, sugar, cocoa butter and dark chocolate nibs are low-cost ingredients by themselves. In the hands of a master chocolatier, the result can earn you forgiveness for leaving dirty socks on the living room floor, show appreciation to that analyst who went the extra mile for your study, or, eaten in private, could get you lucky on a date. The making of a chocolate confection may have a low cost, but the activity adds much of the value to the end product since the ingredients are significantly less valuable than a box of Recchiuti Confections.

So, what do you do with a value chain? Once you have the value chain, in order to understand the behavior of costs for the product you can disaggregate a company (don’t be distracted by the divisions) into its strategically relevant activities. And you can examine the existing and potential sources of differentiation between your company and your competitors. Does your competitor have the ability to deliver a service in the same end-to-end capacity as your company can? Does that make you more interesting to potential customers? Understanding the value chains enables a company to gain a competitive advantage by performing these strategic activities more cheaply or better than its competitors.

What is the goal of Business Architecture?

In my opinion, the goal of a business architecture is to enable a company to focus its services on its customers. If you don’t know how the information in your company is integrated to enable delivery of services and customer satisfaction as well as being able to bill and collect for those services, then your company is in trouble.

Case in point, what happens when you have multiple customer master databases? It is easy for this to happen. In my previous company, we grew by acquisition. With each new acquisition came at least three customer master files, one from the sales group, one from marketing and one from customer service. In my current company, we are in the process of integrating the customer master files associated with siloed products. One of the driving issues is data quality; when you have multiple sources of the same data, but no process for “single source of truth,” it can be impossible to know what is the most current data set for a customer. To achieve the goal of a single customer master file a company has to have an integrated model of customer touch-points. I don’t know about you, but I hate getting “exceptional offer for new customer” announcements from a service provider that I already have a contract with, especially when I see what good deal I would get if I weren’t already a customer. Makes me wonder if a competitor might match that new customer offer.

Rethinking “The Customer is #1” idea

A short tangent, indulge me. I’ve never liked the idea of the Customer being #1. In my mind, the employees should be #1 because if the employees are treated well they will perform well and treat the customer well and make the customer feel like they are #1.

In a previous company that I’ve worked for, if a customer became difficult to work with, one question that was always on the table was, are they worth doing business with? We could quantify that answer in terms of revenue versus lost productivity dealing with them and low employee job satisfaction. There’s a ceramic urn on top of the refrigerator in the employee break room at that company labeled “ashes of former customers.” I can’t tell you how much employee loyalty that urn evokes; I can tell you that in that urn are the names of companies we stopped doing business with because management decided it was bad business.

My employer, Railinc, is a subsidiary company of the American Association of Railroads. Having never worked for a subsidiary company before, I was surprised when I realized that one piece of advice that has been in my toolkit is no longer applicable — Railinc cannot fire any of its customers. We can’t single out a particular railroad and say, “We won’t do business with you.” A new twist in the life of an information worker.

Does making the employee “#1” conflict with the goal of a customer-centric business architecture? Not at all. It just means that a company needs to examine its business goals and determine the different aspects of “the customer,” i.e., revenue source and cost-center if it wants to broaden its definition of “customer.” Customers aren’t just revenue sources; they are also sources for cost, as in customer-retention. Employee-retention is also a quantifiable asset. Revamping the definition of customer is one example of how thinking at the enterprise level changes the scope of a business analyst to business architect.

What does a Business Architect do?

Like the job description for a business analyst, the answer to that question seems to be dependent on the hiring manager. There’s lots of confusion between the role of the enterprise IT architect and the business architect. I can only tell you what I am and am not doing.

Currently my focus is on core elements of the industry, specifically railcar health and railcar utilization. My days are spent as follows:

Formulating frameworks and building models — by the bucket load
Writing concept documents
Critiquing project proposals
Preparing for and conducting knowledge elicitation meetings
Asking a lot of questions
Collaborating, facilitating, more collaborating
Identifying “services” in product offering visions
Tending an organic (constantly changing) ten-year roadmap

I do not research or recommend technologies. That’s doesn’t mean I can be ignorant of past or current technologies. In fact, being older and having been around when some of the legacy systems were built and understanding how difficult it is to migrate off those platforms has been beneficial. I leave the “how” of the solution to the enterprise architects. They come to the business architecture team for the “what do they need to do and why do they need to do it.”

In my current position, my scope of work isn’t a single company. Railinc provides information services to the railroad industry. The business architecture model that my team is building focuses not on a single enterprise but on the entire railroad industry.

What I don’t do is spend any time with UML, write formal requirements and work directly with the product developers. That experience prepared me for how I spend time now — working with people at the railroads, with Railinc business analysts, product managers, program managers, Railinc enterprise and data architects, and external industry subject-matter experts.

I help articulate our products, current and future, in terms of services and value streams. In particular, I analyze railcar health and utilization information and integration points in terms of relationships to all external entities, other enterprise value streams and the events that trigger instantiation. I look at railcar health and utilization information from the perspective of what my company must produce to satisfy its industry partners, compete in a market and deal with its information suppliers.

Summary

If you can’t help but perceive the world around you in terms of business information needs and process and connections; if you can hold multiple points of view simultaneously; if the meta-modeling is part of your consciousness and you’ve had a blast being a business analyst and are looking for something more, then I strongly encourage you to start aiming your career at business architecture.

Are Business Analysts In Danger of Becoming Extinct? Part 2

Written by Glenn R. Brule on October 18, 2011. Posted in Articles.

The response to my article has been overwhelming to say the least. I was pleased to see the genuine interest and passion in support of the role and profession of the business analyst. The many differing viewpoints in and of themselves tell a very interesting story, perhaps worthy of another article?

As I reflected on all of the comments, it occurred to me that the forest had been overlooked for the sake of the trees…the technical trees. Many of you responded with concerns, support and very pragmatic viewpoints where “technical competencies” are concerned. It’s unfortunate, and a challenge BAs and stakeholders alike face every day. However, my intended message was clearly lost in translation. When I referred to “technical competencies”, in the context of the article, I was specifically addressing those tasks, activities and techniques referenced in the Business Analysis Body of Knowledge^®, as presented by the IIBA, and NOT “technological competencies” as they relate to the information technology world.

I hope this clarification will perhaps give a moment of pause and reflection before reading Part 2 of this article, I’m more curious than ever to hear your thoughts, feedback and input.

In this article, I continue my mission to raise the alarm to the potential extinction of the business analyst by emphasizing that regardless of the BA’s professional level, we need to demonstrate quantifiable impact. As I wrote in Part 1 of “Are Business Analysts In Danger of Becoming Extinct? A Perspective on Our Evolution,” I explored the context for the reasons BAs need to use a balanced portfolio of technical and business skills in order to demonstrate their value to the organization. In this article, we’ll examine the appropriate mix of skills based on the BA’s level of experience.

When we set out on a career path, whether it’s police officer, writer, painter, etc., we are rich with technical knowledge and competence, doing a lot of work “by the book.” As we become more experienced and more seasoned, we find our own rhythm, shortcuts and better ways to do things, and come to rely more on our business savvy and skills as we inevitably begin to direct others in performing the technical aspects of a job.

In the beginning of their careers, business analysts start out with the IIBA Body of Knowledge^® and any other materials they can get their hands on as reference for drawing diagrams, researching templates and other technical questions. The new BA relies extensively on skills around requirements analysis and elicitation practices as the core essentials. This requires a high degree of technical fluency; for example, elicitation from a technical perspective requires planning and stakeholder analysis using a variety of different techniques to realize requirements from all perspectives.

In order to conduct elicitation activities with a high degree of accuracy, the BA needs to be aware of which ones, e.g., brainstorming, interview, focus group, survey or questionnaire, are most appropriate. Knowing which method is right and selecting the most appropriate technique increases the efficiency and effectiveness of that activity.

For example, using a survey/questionnaire of 300 people in 10 days of effort using 600 hours as opposed to conducting 300 interviews requiring 1,200 hours is an example of creating an efficient solution that can quantifiably show positive impact on the project. This kind of quantification gives the BA evidence to provide to executives to justify the recommended activity. It also provides the opportunity to demonstrate the cost of not conducting the activity—and, if done properly—the opportunity to:

1. Quantify the results of the survey through carefully crafted questions that would ask stakeholders to rate and rank anything from wants and needs to priorities.

2. Vote on the allocation of requirements based on said data.

The same can be said of requirements analysis—creating the right models, sequences with the right degree of accuracy, plan for activities—these are all technical skills that provide opportunities to show quantifiable impact.

As BAs develop further along they look more at the big picture—how the business runs—and perhaps leave the more technical aspects to another BA or team. Having a mixed balance of both is critical to enable oversight and examination of the work being done, while being able to practically apply career experience based on business skills. So, while the more experienced BA is knowledgeable in both, he or she doesn’t necessarily execute both.

Moving beyond junior technical, worker bee-type of activities, the more experienced BA progresses to the intermediate level where he or she puts a toe in the water with activities such as planning and monitoring. This is where business skills start to come into play to answer questions such as when and what activities need to be done and who are the stakeholders that need to be considered?

Transitioning into a senior role, the BA is acutely aware and well seasoned in technical skills and begins to flex business skill muscle in enterprise analysis-type activities, e.g., writing a business case, understanding business needs, conducting capability analysis, defining solution scope.

What’s the right mix?

It’s helpful to have an idea of the percentage mix of technical and business skills the BA will use throughout the career spectrum:

Career level	Ratio of technical to business skills	Competencies of focus
Junior	80/20	Elicitation and requirements analysis activities and techniques, ability to practice solution assessment and validation activities
Intermediate	60/40	Planning, monitoring, and management of requirements + junior level competencies
Senior	20/80	Enterprise analysis + a high degree of business skills expertise, e.g., critical thinking, problem solving, change management, high impact communication

Given the range of skills sets practiced at each level of experience, the 80/20 rule using a mix of junior, intermediate and senior levels of BAs in the organization is recommended: 80 percent junior and intermediate level and 20 percent senior level. This will create a balance of business analysis capability based on experience, not headcount. It also facilitates a well-rounded BA perspective. For instance, if an organization is top heavy on the senior BA side, there’s the risk of potentially losing objectivity and creativity without junior or intermediate BAs to question or bring a differing point of view.

The levels of experience align essentially with three layers of the BA’s impacts:

Organizational level – This level addresses issues such as key performance indicators, goals and visions, which are typically manifested by a senior BA conducting senior business analysis type activities. An example would be using enterprise analysis to contribute to the development of a solution that increases profitability by a certain percent.
Practices, standards, methods and approaches – At this level, intermediate and senior BAs are seeking to create efficiencies within their practices and processes. They address issues such as how can we do this faster, better? How can we refine our approach/methods?
Activities – This level is task focused, seeking improvement of junior level practices, asking questions such as “can we be more precise?”, and “can we be more efficient with our technical activities?”

The business analyst profession continues to be a work in progress. To keep BAs from going the way of the dinosaur before they’ve had a chance to completely mature takes a balance of skills. With a greater understanding of how BAs can demonstrate their impact and value to the organization with a portfolio of competencies, you’ll better serve your professional development while elevating the business analysis profession too.

Don’t forget to leave your comments below.

Glenn R. Brûlé, CBAP, CSM, Executive Director of Global Client Solutions, ESI International, brings more than two decades of focused business analysis experience to every ESI client engagement. As one of ESI’s subject matter experts, Glenn works directly with clients to build and mature their business analysis capabilities by drawing from the broad range of learning resources ESI offers. A recognized expert in the creation and maturity of BA Centers of Excellence, Glenn has helped clients in the energy, financial services, manufacturing, pharmaceutical, insurance and automotive industries, as well as government agencies across the world. For more information visit www.esi-intl.com.