Skip to main content

Where We Were in 2009 and Where We’re Headed in 2010

Co-authored by Richard Larson

At the close of 2008 we made seven predictions about business analysis and project management trends for 2009. How did we do? This article looks back at our predictions for 2009 and forward to new ones for 2010.

1. 2009 Trend – Convergence of PM and BA Roles.

As the economy tightens, organizations will decrease their project budgets. But, they still need projects done, so look for organizations to try and combine the role of the BA and PM on projects. Project managers will be asked to do more requirements elicitation and analysis. Business analysts will be required to manage more projects. Oh, and by the way – you will need to do that in addition to your normal roles!

How’d we do? It appears that many organizations are, indeed, either merging the roles or completing feasibility studies on combining the roles. Here, also, is a sampling of the comments received in response to my December 2009 blog asking whether or not one person could fill both roles, I received:

  • Johnstde 95% of my projects require me to do the jobs of BA and PM.
  • Drusso The points made agree with trends we’re seeing with our clients and opportunities
  • gmmba, Truth be told. When I am evaluating resumes for BA opportunities, I look for BAs with solid Project Management experience. When I am evaluating Project Managers, I look for solid BA experienc
  • a gues I may be moving to a PM/BA type role and it is unnerving coming from a straight BA positio
  • Hkmartin Some people are skilled in both PM and BA work and can easily shift from one role to the other
  • abhikashyap22 ,My answer to your question will be a “Yes”. A person can perform a BA role and a PM role on the same project.

2010 Trends
Look for some companies to continue to question the separation of roles, while others recognize the importance of the business analyst and keeping it separate. Look for some attempt at role delineation (see 2010 trend summary at end) and how BAs, PMs, and testers can all work together effectively. Organizations will continue to expect business analysts to test requirements, although there will be a growing awareness that the testing process is different from business analysis.

2. 2009 Trend – Greater Emphasis on Requirements in Project Management.

The PMBOK® Guide Fourth Edition “Collect Requirements” contains a number of requirements elicitation techniques. They are a subset of the techniques described in the BABOK® Guide 2.0, so BAs also need to be familiar with these.

How’d we do? It appears that the topic of collecting requirements as part of project management is wide-spread. There have been numerous presentations, webinars, and articles on this topic. The term “Collect Requirements” has crept into our common project vernacular. There are many blogs and discussions about collecting requirements, including who should collect product requirements vs. project requirements, as well as what level of detail should be collected and when. This topic has helped fuel the debate about the role of the project manager and business analyst and who should be responsible for what.

2010 Trends
Organizations will continue to struggle with the role definition of the BA and PM and where the two overlap, such as who is responsible for defining the business problem and product scope. Look for organizations who value both roles to further define responsibilities. Also look for more business analysis Centers of Excellency (COEs) to tackle not just roles and responsibilities, but also requirements processes and templates that can be used during business analysis.

3. 2009 Trend – Change in Requirements Approaches.

We see a continued trend in business analysis techniques continuing into 2009. Here are some to consider:

  1. Slightly less reliance on use cases and movement towards user stories and scenario-based requirements.
  2. Less emphasis on requirements specifications, more emphasis on modeling, prototypes and diagrams.
  3. More requirements management. There will be continued increase in business analysis and requirements planning in 2009. We see more and more organizations using traceability to control and mage product scope

How’d we do? We did pretty well on the first two and part of the third.

  • User stories, along with the agile approach (see below) have been adopted in many organizations.
  • While many organizations, particularly large companies, document requirements in a formal specification, others are opting for less formality on some projects. Also, many companies are using models to supplement textual requirements lists.
  • We’re seeing an increase in the number of organizations that understand the importance of tracing requirements and understand the relationship between traceability and managing scope. In addition, many companies that have adopted Agile methods participate in release and iteration planning. However, in 2009 we anticipated more wide-spread adoption of other business analysis planning processes, such as creating a business analysis work breakdown structure (WBS) or estimating business analysis tasks.

2010 Trends
Organizations will move to documenting requirements appropriately for their projects. They will continue to recognize that one size does not fit all. Waterfall project teams will move to less documentation where it makes sense, understanding that over documenting can be as detrimental as not documenting enough. More organizations adopting Agile methods will understand when documentation is important (for contracts and regulatory compliance, for example) and not use Agile as an excuse for omitting all project discipline. Increasing adoption of requirements management tools will contribute to greater requirements management for organizations who employ them.

4. 2009 Trend – Increased Use of Agile Approach and Techniques.

Integrating Agile methods into project management and business analysis is a trend that will continue in 2009. Currently, the industry has a wide, varied, and inconsistent use of Agile techniques. This trend is likely to continue as organizations adopt Agile techniques and the industry adopts commonly accepted practices.

How’d we do? The adoption of Agile methods, especially Scrum but also including XP, exploded in 2009. The use of Agile is one of the hottest topics at both project management and business analysis conferences, in the blogosphere, and within PMOs and COEs. Scrum user groups continue to grow in numbers and numbers of attendees. The BABOK® Guide is developing an Agile extension.

2010 Trends.
We anticipate that the adoption of Agile methods will continue to increase. There will be more realization within organizations that using Agile methods is not an excuse for lack of discipline, that automated testing tools might be needed to achieve significant benefits, and that techniques such as facilitation and modeling are still important. More organizations will implement methods such as Scrum, and will continue to get positive feedback from both the team and the business clients.

5. 2009 Trend – BABOK® Continuing to Have an Impact.

The practice of business analysis is being positively influenced by the Business Analysis Body of Knowledge (BABOK®). The BABOK® Knowledge Areas of Enterprise Analysis are beginning to gel in organizations, as is the need to do requirements planning. We’re seeing more formality and standardization in the methods, say, of doing business cases, or using traceability to manage requirements.

How’d we do? The number of IIBA members and chapters continue to grow. There were 5,000 members at the end of 2007 and 11, 707 as of January 2010. The number of Certified Business Analysis Professionals (CBAP) continues to grow as well. There were 301 as of January 2008, 479 as of January 2009 and 827 as of January 2010 (IIBA Newsletters). There have been more comments by discussion group members and in articles and blogs that acknowledge the BABOK® Guide as the de facto business analysis standard. However, regretfully, we think that use of BABOK processes such as Enterprise Analysis or business analysis planning has not increased significantly.

2010 Trends
Both project management and business analysis will be recognized as essential to project success. The number of CBAPS will continue to grow worldwide as the tasks and techniques BABOK becomes more widely adopted. In 2010 there will be more of an effort to understand the role of the PM and BA (see above). The relationship between Enterprise Analysis in the BABOK and Portfolio Management in the PMBOK will be the subject of presentations, articles, and blogs. PMI and IIBA will collaborate to clarify the roles and handoffs between project managers and business analysts. This effort will improve the practices of both professions, although they will likely be subtle shifts.

6. 2009 Trend – Business Intelligence Continues to Grow.

This area of information systems has been growing steadily and 2009 promises to have no letup. As BI tools and techniques improve and solid benefits are realized, organizations will invest more and more in this tactic. Since BI relies heavily on tools such as Business Objects or Cognos, the underlying business requirements can be easily overlooked in favor of what the tools can produce.

How’d we do? The need for BI continues to grow, as well as the reliance on automated tools. The attention paid to BI requirements analysis has lagged, unfortunately.

2010 Trends
There will be a continued reliance on tools. Organizations will look to predictive analytics as a way to compete. There will be recognition that the BA is needed to elicit and analyze BI requirements. In his article “Building the Basics Is Key to Launching a Successful BI Program, (Sean: Please link”(http://www.businessintelligence.com/article.asp?id=166&pagenum=2), author: Gary Garris states “Striking the right balance between the type of information required and the framework for delivery requires a defined and methodical approach built on solid governance principles that merge business drivers with appropriate enabling technologies. Look for more articles and webinars on BI requirements in the months ahead.

7. 2009 Trend – “The Economy, Stupid,”

As a past political slogan said: A slumping economy tends to affect travel and training budgets, and this one is no exception. That translates into fewer trips to national conferences or travel to out-of-state training classes. Have you noticed the big increase in webinars as a way of exchanging information and interacting virtually without travelling? Watch for more of the same in 2009.

How’d we do? As the economy continued to slump, the number of webinars increased dramatically. Many national and regional conferences had fewer attendees than the previous year. BAs and PMs have found new ways to get and share information through social media and virtual discussion groups.

2010 Trends
“Discretionary” budgets will continue to be tight. Travel funds for conferences will not increase significantly. Webinars will continue to be a quick, inexpensive way to increase knowledge and obtain credits for recertification. In addition to the continued growth of social media, both virtual and online training will increase as many organizations’ training budgets remain static or decrease.

Other 2010 trends include opposing forces in these areas:

  1. Roles. Look for both more role delineation (PM and BA, BA and tester, for example) as well as less role delineation as Agile team members wear multiple hats.
  2. Governance. Look for more governance on some types of projects, such as BI and less governance on those using Agile methods. Look for a move towards more standardization of requirements processes and templates (established in growing numbers of Centers of Excellence), and less with Agile projects. More business process management and more formal and informal process modeling as a way to uncover the gaps in what an organization currently does and what needs to be done as a result of implementing a new product or software.
  3. Tools. There will be both a greater reliance on tools (such as Agile testing tools) and more adoption of low-tech tools, such as low-tech prototypes.

Don’t forget to leave your comments below


Elizabeth Larson, PMP, CBAP and Richard Larson, PMP, CBAP are Co-Principals of Watermark Learning (www.watermarklearning.com), a globally recognized business analysis and project management training company. With over 30 years of industry experience each, they have used their expertise to help thousands of BA and PM practitioners develop new skills. Both Elizabeth and Richard are among the world’s first Certified Business Analysis Professionals (CBAP) through the International Institute of Business Analysis (IIBA) and are contributors to the IIBA Business Analysis Body of Knowledge (BABOK). They are also certified Project Management Professionals (PMP) and are contributors to the section on collecting requirements in the 4th edition of the Project Management Body of Knowledge (PMBOK).

What is the Future for Senior Business Analysts?

futureforsenior2Now that you are recognized as a senior business analyst, what can you look forward to in your professional future?

BAs who have ten or more years of experience often feel “topped out” in their career path because most companies assume that senior BAs will develop into something else, such as a project manager or product manager. If a business analyst wants to extend herself beyond a single business function or provide more consultative guidance to her business unit, she typically has to change roles and embark on a different career path. Once a BA’s head has hit the company’s career path ceiling, there is often no place to go but to another company for advancement. Even so, most companies do not have a growth path for a business analyst who is already senior.

In this article, we will look at options for our professional future and talk about ways to extend ourselves professionally.

Where BAs Come From

Many of us came to have the business analyst title through roles such as

  • Power User
  • Developer (or “Programmer”, or “Systems Analyst” to use the old-fashioned terms)
  • Quality Assurance Analyst
  • Database Administrator
  • Technical Support, Customer Support specialist
  • Infrastructure (IT) specialist

Managers recognized that in addition to our remarkable analytical skills we had special qualities, such as our ability to ask questions about the big picture, or our ability to be the communications bridge between a customer and the technical team, or be the communications “hub” for the entire technical team. We found ourselves playing the role of the business (systems) analyst whether or not we had the title.

Currently the typical growth path for a senior BA is to become a

  • Project Manager
  • Product Manager
  • Account Manager (internal customers)

In some companies, a senior BA can add the following titles to their list of possibilities:

  • Architect
  • Business Process Analyst

In my humble opinion, one of the best things a BA can do for him/herself is to get savvy about process analysis. If your current position keeps you focused on the details, consider coming up for some air, learn to analyze the processes that are generating the details and the predictable system failures that you are drowning in. Maybe the root of the problem is not in the data itself but in the processes around the data.

Maybe you are already spending a lot of time with the system architects in IT, and the business architects on the business side of your company. Architecture is the art and science of designing structures whether they are physical or logical. With all of your experience, you may be at a point in your career where you’re ready to focus on design.

Jonathan Kupersmith’s blog article, “What?! You Don’t Want to Be a Project Manager” summed up the BA to PM transition controversy quite nicely. Product manager and account manager both have the word “manager” in the title; some people assume that becoming a manager of some sort is the only way to show that you have achieved success. Let’s say that you are an iconoclast, not driven by what other people think or the strictures of your country’s norms – you don’t want to be a manager, you want to be recognized as a senior business analyst and you want career growth. Is that so much to ask?

What Does it Mean to be Senior?

Being senior is more than just “years on the job”. Being a senior BA implies:

  • Mastery of core business analysis competencies and corresponding skills
  • Both breadth and depth of knowledge and experience
  • Knowledge of business processes
  • Leadership

The IIBA identifies these categories of core competencies, called underlying competencies in the BA Body of Knowledge (BABoK):

  • Analytical Thinking and Problem Solving
  • Behavioral Characteristics
  • Business Knowledge
  • Communication Skills
  • Interaction Skills
  • Software Applications

These competencies have nothing to do with domain knowledge; these are the competencies a BA brings to every job assignment. The skills that correspond to these competencies are:

  • Facilitation
  • Requirements Elicitation
  • Modeling
  • Negotiation
  • [Process] Change Leadership
  • Requirements Planning & management
  • Stakeholder Management
  • Verbal Communications and Presence
  • Written Communications and Documentation
  • Technology Understanding and Application

As a senior BA, you may or may not have equal levels of mastery of these skills. The three aspects of being a leader as BA that I want to call out are, being an agent of change, being a speaker of truth, and being a role model. These three aspects are key for senior BAs to set their sights on what the BA Body of Knowledge calls “Enterprise Analysis”.

Being acknowledged as the “go to” person in your group can feel great because you can share your experience and knowledge with others. Being senior can also bring on an empty feeling. Most BAs need new challenges; we need to keep learning; we can’t survive on the same old problems. No one wants to live with an old leaky faucet; not only does the dripping sound drive us crazy at night but knowing that water is being wasted without taking action is morally wrong. We BAs need to find satisfying ways to apply our brain power.

Kathleen Hass has written a wonderful book, From Analyst to Leader – Elevating the Role of the Business Analyst. I recommend this book both to business analysts and managers of business analysts because Ms. Haas and her contributors have accomplished an impossible task, they have articulated in just 120 pages what leadership means for a BA in the two overall contexts that a BA may work in: a project, and a business solution life cycle. Moreover, there is a chapter on establishing a Business Analysis Center of Excellence.

Next Steps

As a senior BA who is feeling that the ceiling is coming closer and closer to the top of your head, how do you extend your knowledge and experience range? Think about this in terms of how big a step you want to take, a small step, a mid-sized leap, or a big leap.

  • Small step

Stay within your general domain (or business process) but add a new, closely-related sub-domain (or business process) to complement your existing specialty area.

  • Mid-sized leap

Extend your activities into a new domain within your current business unit, so that you can take advantage of the trust-based relationships you have with senior and executive managers.

  • Big Leap

Extend your activities into an unrelated domain where you will have to build new relationships with managers and single contributors. This kind of leap is not for the faint of heart.

Let’s look at an example.

futureforsenior1

A small step would be working in Finance where you are a Senior BA in sub-domain F1.2, and taking on activities or responsibilities for closely-related sub-domain F1.1.

A mid-sized leap would be working in Finance where you are a Senior BA in sub-domain F1.1 and taking on activities or responsibilities in related sub-domain F3.1.

A big leap would be working in Finance and taking on activities where you must learn about the IT infrastructure that supports the business applications used in Finance.

Here’s what you need to think about as you decide how much you want to start extending yourself:

  • What is your risk tolerance?
  • Do you trust your command of the core competencies?
  • How fast do you absorb new information?
  • How fast do you build allies?
  • How badly do you want to influence improvement?

As a senior BA, you are a subject matter expert. Do you remember what it feels like to “not know”? What is your tolerance for “not knowing”? What is your tolerance for not having allies? Will your ego allow you play the “I’m new, please forgive me if I don’t know how this works and I have to ask a lot of questions” card. If you dive in and the waters are too deep, will it be okay for you to take a step back? The more comfortable you are with “not knowing”, learning new information fast, building new allies quickly, the bigger the leap you can take.

When you have answered these questions for yourself, determine how to frame your request to expand your activities in a manner that shows your manager that you are thinking about the benefit to the company, not just your career path. As a senior BA you are probably quite well aware of where there are needs in your company.

Enterprise Analysis

Defining a business need and making the business case for finding a solution to meet that need is heart of the BA BoK knowledge area called Enterprise Analysis. The tasks involved in this knowledge area are defining the business need, assessing the capability gap, determining a solution (high-level) approach, defining the solution scope (high-level), and defining the business case. The IIBA identifies the following skills for this knowledge area:

  • Benchmarking
  • Brainstorming
  • Business Rules Analysis
  • Decision Analysis
  • Document Analysis
  • Estimation
  • Feasibility Analysis
  • Focus Groups
  • Functional Decomposition
  • Interface Analysis
  • Metrics and KPI
  • Problem or Vision Statement
  • Risk Analysis
  • Root Cause Analysis
  • Scope Modeling
  • Strengths, Weaknesses, Opportunities, Threats (SWOT) Analysis
  • User Stories
  • Vendor Assessment

I would add “writing a business case” to the list of skills as a business case is a well-understood documentation artifact that has a commonly understood structure and content. Typically, senior BAs have competence in some but not all of these skills. Senior BAs take note – when you are thinking about where you want to expand your knowledge and experience, think about the skill development you will need. Just like changing the batteries in the smoke detector in your home when we switch to daylight savings time, the beginning of the year is a good time to update your professional development plan – what do you want to accomplish this year? Your manager may not be able to respond immediately to your request with a new assignment, but your manager may be able to approve training for you in anticipation of helping you take on a bigger challenge.

Summary

We started with the question, “What is the Future for Senior Business Analysts?” We made the assumption that you don’t want to be a manager, and you are perfectly happy being included in architectural discussions but you like being a business analyst. There are two issues here, the first is your skill set, the second is your title. With respect to your skill set, think about adding or improving the Enterprise Analysis skills listed above. Also think about adding process analysis and process engineering to your tool kit.

The thornier topic is your title because job titles are defined by your company’s Human Resources group. Enlist your manager’s help – ask to see the job descriptions for business analyst positions for all grades. If you are truly “topped out” in your grade level, ask If there is job structure for another role that could be used to create a career growth path for senior BAs. For example, what is the highest position that a single contributor in the engineering organization can achieve? Could that model apply to the business analysts? It may take some time and considerable energy from your manager to help HR understand the need to create “head room” for a job family that was not envisioned to support senior contributors. We senior BAs need to influence this change both for ourselves and for the BAs who are going to be turbo-charged in their development, thanks to existence of the BA BoK. The next ten years will do more than set precedent; the next ten years will establish a standard practice of cultivating talented, battle-hardened and business-savvy BAs to share their knowledge and experience with the entire enterprise.

Don’t wait for the business analyst job structure to catch up. Get out there and be the role model for what you believe a senior BA can do. Take it one step or one leap at a time.

Don’t forget to leave your comments below


Cecilie Hoffman is a Senior Principal IT Business Analyst with the Business Analysis Center of Excellence, Symantec Corporation. Cecilie’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She writes a blog on her personal passion, motorcycle riding, at http://www.balsamfir.com. [email protected].

Get Your Head Out of the Weeds!

getyourheadIn our profession there is often talk about business analysts needing to get out of the detail and take a look at the bigger picture to make sure your efforts are still heading towards the goal of the project and the company goals. I refer to the syndrome of never getting out of the details as being “in the weeds.” In theory, looking at the big picture every now and then makes perfect sense. I have been asked by BAs how do you do it and when is a good time. I thought I would give an example of how I try to build-in project milestones where I force myself to pull back the weeds and take a look to make sure I am heading down the right path. Now, on agile projects this should be built in to the process. Before beginning a new sprint, the team should be looking at the big picture and determining the right path. The example below addresses how I did this on a recent project using more of a traditional approach.

The Project

I was the lead analyst on a project with a goal to elicit and analyze the business processes for four sister companies to help them determine if it was feasible to build an enterprise-wide technical solution for all companies. The project was initiated because each company had built and maintained systems. In many cases there were multiple systems with the same feature set. This project was part of a large initiative to reduce costs. The thought was, if there was one system rather than four, the long term cost to maintain and enhance the system would be less. The first step we took was to identify every business process conducted by each company and come to an agreement on all the process names. It was imperative to compare apples to apples. That effort revealed 145 unique processes to analyze. Yikes…that’s a lot! I’m not even going to bring up the timeline given to us. Let’s just say it was unrealistic.

Insert Milestones

The business stakeholders did not want any recommendation until all the processes were analyzed. They felt very strongly that without seeing the analysis of all processes, there was no way they could make a decision. Deep down I knew if we waited to show results of our analysis until the end there was a huge risk of us missing the mark. So I convinced the business stakeholders that we should attack the 145 processes by breaking them into smaller logical groups. We organized the 145 processes into 16 high-level groups. That is about nine processes per group which was very manageable chunks. The project plan was developed to attack the highest priority groups first. I also was able to have everyone agree we should stop at the end of each group and validate our understanding of the processes, present similarities across the companies, present variations, as well as the benefits and challenges of moving forward with an enterprise solution. In essence, we applied an agile approach under the disguise of a traditional approach. This is where we had milestones built in to the plan to get our heads out of the weeds.

The Result

After we analyzed the first group, we validated our understanding of the processes, presented similarities across the companies, presented variations, as well as the benefits and challenges of moving forward with an enterprise solution. Then we asked two questions to the group.

  1. Did the information provided give you enough information to make a decision about moving forward with an enterprise solution?
  2. Was there a reason to continue to the next group?

We wanted to uncover any issues our stakeholders had with what we presented. We had to know if we were doing what was necessary to meet the project objective. This gave us an opportunity to inspect how we were doing and what needed to be changed. Based on the answers, appropriate changes were made to our approach and we were asked to continue to the next group.

After the next group was complete, we asked the same questions. This time the business was able to determine that it was no longer necessary to compare business processes across the four companies. They had enough information to realize building an enterprise solution was not worth the investment. The initial project was canceled and new projects were initiated to help each company build update, and maintain their systems. In this case, our path ended before we anticipated.

By building in milestones in our project to get out of the weeds, two critical things happened:

  1. The initial project was stopped, potentially saving approximately 200k in cost.
  2. By stopping the initial project and moving forward with implementation projects for the companies, they will realize the benefits of new and enhanced systems four months earlier.

By getting your head out of the weeds and checking to see if you are still headed down the correct path is a characteristic of a seasoned business analyst. As you gain more experience you will naturally look up every now and then. If you are not there yet start inserting milestones in your plan to give you definite points in time to look up and make sure you are headed down the right path.

Stay on the right path!

Kupe

Don’t forget to leave your comments below


Jonathan “Kupe” Kupersmith is Director of Client Solutions, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at [email protected]

Requirements Driven Test Management

According to the Standish Group’s Chaos Report, 90% of IT projects are delivered late and 66% of them are not considered successful. Surveys show that more than 50% of the project failures can be attributed to problems stemming from Requirements Elicitation and Management and more than 20% are due to Ineffective Testing.

This situation can be best explained with a simple analogy from nature. The software development lifecycle is like a river with requirements at its source. If you can’t clean the river at its source, you will have a dirty river flowing down the hill. A reactive rather than a proactive approach to clean the river will increase the costs and risks exponentially. The proactive way to overcome this situation is by integrating Requirements and Test Management activities and formulating a Requirements Driven Test Management Process. To build a RDTM Process the following critical success factors should be in place:

  • Early Testing. The testing activities should start in parallel to requirements definition without waiting for coding. Finding and fixing the requirement defects will lead to early prevention of flaws in design and coding process. Applying Early Testing as a principle will also have a positive quality assurance impact on business analysis activities.
  • Use Case vs. Test Cases. In most of the projects, use cases are used as test cases. But these test cases only contain positive cases lacking forced error (negative) test scenarios which help in identifying most of the defects. In good practice approaches test cases should be prepared as a combination of use case scenarios and negative scenarios. Negative test cases are best developed by using test design techniques like equivalence partitioning, decision tables, boundary value analysis etc.
  • Independent Test Teams. Positioning testing as a nice to have rather than a must have, last minute, additional task for developers or BAs resulted in incomplete and ineffective testing of applications. In order to avoid this problem, independent test teams with test automation capabilities should be established in organizations. Nowadays, CIOs are investing in Centers of Excellence for Requirements Engineering and Test Engineering teams as separate disciplines.
  • Requirements Traceability and Test Coverage. The traceability matrix is a helpful tool to ensure that requirements have been met and all changes are addressed. By using traceability matrices, requirements can be referenced beside relevant test cases and test coverage ratio can be monitored at each stage of the project. Requirements coverage should be also used as a Key Performance Indicator for test teams and should be evaluated as test exit criteria.
  • Requirements vs. Test Automation Tools. Requirements Driven Test Management necessitates the integration of requirement management and test automation tools. In the selection of test automation tools, the requirements coverage monitoring abilities should be a selection criteria, in addition to standard test case and bug tracking functionalities.

Beyond all the critical success factors discussed above, most companies require a paradigm shift in their culture to put requirements driven test management into reality.

Don’t forget to leave your comments below


Emrah Yayici is the Managing Partner of Ba-Works Business Analysis Services. He is the president of IIBA Turkey Istanbul Chapter. He has worked as a consultant for Arthur Andersen and Accenture on various international technology and management consulting projects. He studied Industrial Engineering and Economics in Middle East Technical University. He has published many articles and participated as a speaker at various conferences on business analysis and software testing. He is a strong supporter of business analysis and software testing professions and supports this vision with active roles in global and local non profit organizations.

Business Analysts; The CEO’s Army

As the economy slowly recovers, businesses and governments continue to look at ways to maximize their organizational potential with the human capital they currently have. Over the years several management strategies have been presented to ensure consistent long-term performance (and outperformance). Methodologies such as Six-Sigma quantify results to identify opportunities for improvement and monitor subsequent performance. Others take a more qualitative approach and look to unleash the most important asset any organization has – its employees.

One management strategy that was formalized in the 1980s focuses on organizational improvement through ‘inverted strategic analysis’. Management by Wandering (or Walking) Around (MBWA) was introduced in Tom Peters’s book “In Search of Excellence“. Instead of coming up with ideas in the boardroom and communicating these initiatives to lower-level employees to implement, MBWA flipped this model upside down. Management (particularly the CEO) is encouraged to meet with as many personnel (particularly front-line staff) as possible to understand the current state of the organization, learn what is working and get suggestions for what can be improved and how.

Several companies over the past 30 years have followed this management style, including HP, GE, Pepsi, 3M and Wal-Mart. Recently Costco’s co-founder and CEO Jim Sinegal was designated as one of America’s Best Leaders in 2009 by US News & World Report magazine. For decades Jim has effused the MBWA ethos by “store hopping … about 200 days out of 365”. Former Procter and Gamble CEO A.G. Lafley also made it a priority to listen to employees and customers to ensure that strategy and operations at one of the largest corporations were aligned as much as possible.

These examples demonstrate that it makes sense for leaders to keep a pulse on their company by staying in contact with as many people within the organization as possible. However, the larger the company the harder and more impractical it is to spend a large amount of a leader’s time on such activities. How can a CEO get the knowledge needed to ensure they can devise appropriate and relevant strategy while at the same time receive feedback on whether the strategy can and is being executed effectively? I believe that business analysts can fill this gap by becoming the CEO’s “eyes and ears”

As a profession, business analysts have the qualities required to listen to a group of people and then communicate essential information elicited from this group to others. Whether it’s software requirements, product ideas, operational efficiency suggestions or customer feedback, business analysts have the skill set to gather, prioritize, manage, maintain and collaborate with stakeholders to meet the strategic goals of the organization. Most BAs experience this on a day-to-day level, typically between internal business units and the IT organization. But I believe that business analysts can leverage these skills to help the organization in a far greater capacity.

Some business analysts are already well-suited to play the role of the CEO’s sounding board. Those who are assigned to one or more business units typically become intimate with the people and processes that make up the sub-organization. Often these BAs will be privy to knowledge that otherwise has no outlet; whether it’s hearing about issues as to how a certain process operates, or hearing first or second hand feedback from customers about a product or service offered.

Business analysts need a channel to be able to relay this information throughout the organization and ensure that ideas can be systematically evaluated and executed in the appropriate context. Usually, BAs know how to handle this information and leverage it to improve the organization if it’s IT related, but there typically are not structures in place to handle suggestions that would impact other external units.

As business analysts, we often see or hear about opportunities before the decision makers in the organization know they even exist. In order to successfully capitalize on opportunities, decision makers need to have such information in their hands so they can decide whether to act on it. How can we get this information to them in a timely manner?

While each organization is different, here is a proposed framework for enabling business analysts to relay the pulse of the organization to upper management:

  • Have at least one business analyst assigned to work with each business unit on a regular basis. This will allow the BA to get a level of expertise in the business area and will provide staff within the unit with a go-to person to discuss requirements or suggestions for improvement. The number of analysts you need per area will vary greatly depending on the size and structure of the organization. You may only need one BA to cover several units or several BAs to cover one unit.
  • In addition to informal information gathering that will occur as part of a BA’s normal activities, hold formal sessions occasionally to generate new ideas. This does not have to be your typical brainstorming session, and the activity can be targeted to a specific group based on their skill set (although I recommend allowing everyone to do the same activities, as you never know who has a hidden talent in a certain area). For example, have new product contests that pit teams from different areas against each other. As West Paw Design found out, employees from any area can have a creative bent that will improve the company’s offering.
  • Come up with a process to evaluate the information you receive. First you need to classify the information – is it a business requirement, a process improvement suggestion, a product or service offering suggestion, etc.? Each type of information will need to be dealt with via its own process. For example, business requirements may need to be collected and a business case developed for meeting the identified needs, either through technology or process changes.
  • Ideas and suggestions may need to be channeled through some sort of review process. Depending on the size of the organization, it may not be feasible to have all suggestions placed in front of upper management. A vetting process is recommended, performed by individuals who will be held accountable for the decisions made (i.e. which suggestions are to be brought forward). I would recommend that business analysts are responsible for overseeing this process and can participate but are not the ones who make the decisions – this should be left to a group that upper management has confidence in with such matters. As part of the review process, I would look to have an absolute grading threshold rather than a ‘Best X ideas’ threshold. This is not meant to be a one-time event – some months you may get several great ideas while others you may get very few.
  • Have the originator of the whittled-down list of suggestions and ideas present their suggestions to upper management on a regular basis. I would recommend allocating a flexible amount of time based on the number of ideas that have passed the review process. BAs should be in the room to hear the feedback and thoughts of upper management, and to help make suggestions on how to implement the ideas, particularly if it requires effort from many different areas of the organization. BAs can also collect feedback from management to improve the overall process and to communicate decisions and results back to others in the organization.

If such ‘internal engagement’ concepts are foreign to your organization or your organization is not used to tackling opportunities across organizational boundaries, setting up a structure similar to the one above may take a great amount of effort. Here are some suggestions on how to get started on the road to a formal structure.

  • Learn how upper management sees their own roles and how they divide their time currently. Ask them what they’d like to see improved internally in the organization and what sort of things they would do if they had more time. With this information, look for ways to suggest having BAs do some of the ground work on their behalf.
  • Talk to front-line employees and ask if a) they feel they understand the higher level goals of the organization and b) if they feel their voices are heard higher up in the organization. Use straw/anonymous polls to have some concrete numbers to discuss underlying needs with upper management.
  • Leverage the PMO or BA Centre of Excellence within your organization to cultivate ground-level staff buy-in and build awareness for Management by Wandering Around principles. Look for case studies that have demonstrated how such techniques improve financial and operational performance within an organization such as yours.
  • Get BAs on board through the Centre of Excellence. If you don’t have one, start an informal community of interest and discuss ways for BAs to play a more prominent role in the organization.
  • Implement the technique without the structure – find a relatively small opportunity that you can execute on and take it all the way. For example, let’s say BAs are hearing about how everyone dislikes the vacation approval process. Talk to HR about the chance of improving the process by getting people from around the organization involved. Hold a lunch session where people can break up into teams to come up with a new process. Have HR managers review the ideas and pick a winner (with a small prize going to the winning team). They don’t necessarily have to implement the idea as-is, but follow up with them to see how feasible it is to implement a variant to improve the process. Once you have some informal successes, present your results to upper management.

CEOs have many people they need to work with in order to achieve the goals of the organization. They simply can’t be everywhere all the time. Business analysts can extend the reach of the CEO by being a two-way conduit for information that will impact the strategic direction and operational excellence of the organization. A strong, formal structure to perform these tasks will help everyone in the company know that they have a chance to play an important role in the direction of the organization, regardless of their job description.

Do you already have a framework like this set up in your company? If so, do BAs play a part in the process? If so, let me know in the comments section below.

Don’t forget to leave your comments below


Jarett Hailes is a Business Consultant with Larimar Consulting Inc. He has worked with large and small organizations as a Business Analyst and Project Manager, and is also a Scrum Certified Product Owner and ScrumMaster.