Author: Glenn R. Brule

Do You Measure Up?

Written by Glenn R. Brule on March 8, 2011. Posted in Articles. 1 Comment on Do You Measure Up?

If there’s one aspect of business analysis that bears greater emphasis and attention, it’s measurement. Quantification and measurement are the business analyst’s sure-fire means to show his or her value to the organization as well as the value of the profession. However, BAs often aren’t as diligent or knowledgeable as they should be about measurements.

One of the top requirements management and development (RMD) trends to be on the lookout for this year is greater balance between the BA’s soft skills and technical proficiency with graphical modeling, cost estimates, risk analysis and other measurements. The important thing to remember is that measurements don’t have to be complicated; in many cases a spreadsheet and a calculator will suffice.

Now, let’s look at how to provide measurement procedures and techniques to gauge the value of business analysis as the organization moves from the as-is to the to-be state.

Start With a Three-Pronged Approach

Often the reason BAs don’t adequately measure is because of uncertainty or perceived complexity of measurement requirements. When thinking about measurement, it’s helpful to understand the delineation of the three key areas of the BA’s focus, each of which will demonstrate a close linkage to the others:

Organizational measurement
Process measurement
People/performance/skills measurement.

Organizational measurement looks at business performance to determine whether the BA’s contribution had an impact on success metrics. Measurement is one of the key techniques for charting the course for deconstructing and reconstituting the organization to verify strategic goals are being met.

Consider another of this year’s top RMD trends-the key role RMD will play in organizations regaining market share. The means by which market share can be increased include:

reaching a new demographic
putting a new spin on an existing product
adding, removing or improving on existing services
creating a new efficiency.

At their foundation these goals and objectives have a corresponding financial value which the BA can measure.

At the process level, using songs available from iTunes as a hypothetical example helps illustrate how the BA’s measurement is critical to creating greater efficiencies. Consider, for instance, that the organization states a business need to increase growth by 10 percent. Raising the price of a song from $.99 to $1.29 increases profitability, but doesn’t increase market share. Looking at the variables that address market share, the BA would examine key performance indicators-song sample time, number of clicks it takes to buy a song, promotion and advertising-and measure the impact they have.

Measurement can also be used to determine if an organization has the right people in place with the right skills by identifying areas of competencies and gaps. For example, a business analyst may be a highly effective facilitator of requirements management, but poor at modeling techniques. This disparity in skills sets will obviously impact project efficiencies.

Measuring From the Top Down

Determining measurements for each of these three areas fits within the context of the following “step top down” chart which depicts the focus areas of a project, and also serves as a guide of signposts indicating where measurement, and the opportunity for creating greater efficiencies, should take place.

Take, for example, an organization that determines a business need to become the exclusive provider of Class A widgets. How that will be accomplished is established in goals and objectives, which require creating new efficiencies, whether by developing a new product or service, reducing production time, or increasing production levels, among other options.

The organization’s business policies and rules dictate the manner in which the organization conducts itself, and their impact provides distinct outcomes that can be measured. This measurement provides the opportunity to evaluate whether a rule or policy should be changed.

Measurement at the goods and services level assures that the organization is selling the right products and providing the right support services. This is where measurement can determine questions such as whether enough of a product is being sold or if the product being sold is meeting market demand.

Processes help accomplish the delivery of the organization’s goods and services, and measuring their outcomes are critical to determining whether greater efficiencies can be created.

Tasks and activities are the individual components that are necessary to support the process. Their performance and outcomes can be measured so that changes such as reducing or consolidating steps of a task can shorten delivery or output times.

A favorite exercise that illustrates the concept of measuring throughout project levels is applying business analysis skills and techniques to baking a cake. Starting with a business need to produce a homemade chocolate fudge cake, consider the requirements that go into the final product. What ingredients will be used, where will they be sourced, and where and in what kind of oven will the cake be baked? Where can improvements be made in how the cake is created and in the quality of the final product? Creating greater efficiencies in the various steps to baking a cake requires good measurements that can demonstrate what the BA’s skills contributed to the mix.

The Quick and Dirty Checklist of Measurement Techniques

In A Guide to the Business Analysis Book of Knowledge® (BABOK®), Chapter 9 provides a high level overview of BA techniques, which include useful methods for measurements that BAs should utilize throughout a project or initiative. To avoid getting bogged down and overwhelmed with measurements, one key suggestion to remember is to conduct measurement at a frequency that is acceptable or in alignment with the project complexity. With that in mind, here are the essential BABOK techniques to refer to when gathering measurements:

9.1 Acceptance and Evaluation Criteria

These are the minimal set of requirements necessary for the implementation of a solution and the set of requirements used to choose between multiple potential solutions.

9.2 Benchmarking

Benchmarking measures the results of one organization’s practices against another’s, and compares current outcomes with previous outcomes. Anything pertaining to the organization, processes or people can be benchmarked.

9.8 Decision Analysis

Decision analysis enables the evaluation of different options and is particularly helpful under uncertain circumstances. The BABOK describes particular tools to use to analyze outcomes, uncertainty and tradeoffs.

9.10 Estimation

The eight estimation techniques in the BABOK traditionally have been in the project manager’s toolkit, but they can be applied to business analysis as well. They can help develop a better understanding of the potential costs and effort that an initiative will incur.

9.16 Metrics and Key Performance Indicators

A metric is a quantifiable measure of progress and can be used to measure a Key Performance Indicator, an indicator that shows progress toward a strategic goal or objective. As previously stated, less complexity is preferable with measurement, so whenever possible, select only three to five indicators for metric reporting.

Measuring Will Show the BA’s Value

For BAs, it’s critical to show quantification of the input they have provided and be able to definitively state that business analysis resulted in a five percent increase in profitability or a 10 percent time saving in a process or any other relevant metric of improvement. Though many organizations struggle with what should be measured, these techniques and methods will help demonstrate what the business analyst has contributed. Measurement, after all, is as straightforward as baking a cake.

Don’t forget to leave your comments below.

Glenn R. Brûlé, CBAP, CSM, Executive Director of Global Client Solutions, ESI International, has more than 20 years of business analysis experience. He works directly with clients to build and mature their BA capabilities, drawing from the broad range of ESI learning resources. A recognized expert in the creation and maturity of BA Centers of Excellence, he has helped clients in industry and government agencies across the world. For more information visit http://www.esi-intl.com/.

Know When to Say When; How Not to Get In Over Your Head With Metrics

Written by Glenn R. Brule on May 18, 2010. Posted in Articles.

As business analysts we can agree that benchmarking is important, but from that point on we’re likely to find the conversation diverges. Differences abound in approaches of how and what to benchmark in order to prove value. Organizations become overzealous in what they want to benchmark and scorecard in their drive to create greater efficiencies. However, a key component for developing and monitoring successful metrics is ensuring that they are in alignment with the maturity of an organization. Knowing when to say when can enable less mature organizations to develop metrics that are both useful and appropriate at the developmental level.

Benchmark People and Process First

In a previous BA Times article on managing metrics, the author and my esteemed colleague, Keith Ellis, made the case for creating multiple point metrics for people, techniques, process, technology, organization and documentation standards. While creating multiple-point metrics may be the best possible scenario, it is an enormous undertaking and, given the maturity of an organization, the least likely possible scenario the organization can accomplish successfully. An organization that lacks BA maturity would do well to start with a simple approach to metrics that considers people, process and tools, with a greater emphasis on the first two.

I highly recommend forming a team of individuals to work together, ideally in a requirements workshop setting, to determine the metrics to be monitored. Select a maximum of five things to measure for a benchmark. Keep in mind that the metrics don’t have to be exact. A “swagged” or estimated number calculated with simple mathematics and a plus/minus degree of accuracy can be used when there are no specific data elements readily available and should be acceptable until a level of maturity is reached. As the organization begins to mature, so too can the details being measured, the formulas used to calculate those measurements and the accuracy of the metrics.

Processes are interdependent and complex, so restrict yourself to three to five processes. Basic measureable process-related activities could include such items as time to complete an iteration, number of change requests and total number of iterations. Also, look at the solution development lifecycle and pick one or two that are bleeding the most. Finally, schedule benchmarking on a monthly basis. One year out is too late for a remedy, and with fewer metrics to benchmark, you will find the task is quite manageable.

Tools really shouldn’t play a role in developing and monitoring metrics, but they invariably do when an organization begins to cloud and confuse what level of metrics should be assessed. It’s important when using this simple approach to remember that knowledgeable people and refined processes are needed before you can select a tool. A tool is only as good as the people and process using it. A simple SWOT (strengths, weaknesses, opportunities, threats) analysis will help a team to quickly ascertain appropriate people and process metrics.

Scorecarding Metrics

Scorecarding is very important for measuring how well activities are being executed and individuals are performing. It should be related to goals and objectives and show a demonstrated relationship with benchmarking to people and process (and tools, if they’ve somehow gotten into the mix). However, scorecards are often put in place and not used because they’re so complicated or they don’t relate back to benchmarks.

Even in singular projects, scorecarding should focus on one to three things. Take, for example, two or three benchmarks that would be measured for running a requirements workshop. One workshop iteration takes 40 hours of effort for planning, execution, validation, etc. The next workshop is conducted after training people and reduces the workshop effort to 20 hours. The scorecard would indicate a 50 percent increase in efficiency.

Project Comparison

Side-by-side paired project execution has the potential to be a valuable benchmarking tool, as long as it doesn’t become too burdensome or complex. Keep in mind that no two projects are identical so give yourself some leeway in finding comparable projects. For instance, a $100,000 project could be benchmarked against a $150,000 project. Then, follow two or three things from project to project and be prepared to evaluate five to ten projects that are similar in nature.

Ongoing Reviews

Peer reviews, contract reviews and structured walkthroughs can increase efficiencies more effectively than look-back reviews conducted after the fact. The reviews should be done through the entire process as iterative functions so that by the time you’ve gotten through a project, you should be confident in your scorecard data and benchmark comparison.

Toward Positive Financial Impact

As an organization matures, overall project costs, return on investment, internal rate of return and the time spent on validating output of interviews, requirements workshops and other BA functions will build toward performance improvement, not only for individual projects but also for project portfolios. This will enhance the value of business analysis and the positive financial impact that can be realized. An organization that lacks in BA maturity should take a simple approach to measure its performance. When it comes to requirements metrics, don’t try to run before you can walk.

Don’t forget to leave your comments below

Glenn R. Brûlé, CBAP, CSM, Executive Director of 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. ESI, a subsidiary of Informa plc (LSE:INF), helps people around the world improve the way they manage projects, contracts, requirements and vendors through innovative learning. For more information, visit www.esi-intl.com.

How to Become (or Manage) a Successful Business Analyst

Written by Glenn R. Brule on March 23, 2007. Posted in Articles.

Completing information technology projects on time and on budget is both essential and a struggle for most organizations. Business analysts can help shepherd projects through to successful results by gathering requirements from a business area and presenting them in ways that are understandable and actionable by the organization. Unfortunately, the business analyst’s job description is often vague. While many organizations know what needs to be done, they don’t know how to identify and develop the skills necessary to meet these needs.

As such, we’ve outlined here eight essential competencies necessary for success in this job. For each competency below, we explore the skills, knowledge and abilities inherent to each competency and provide practical tips for using these competencies as guidelines for improving the efficiency of business analysts within any organization. By definition, a competency is made up of three components: knowledge, skill and ability. Knowledge considers “what is being measured?” Skill looks at “how is it done?” Ability examines “to what degree can it be done?”

Competency #1: Eliciting Requirements On the most basic level, the business analyst’s job is to gather and document user requirements. Requirements are needed by a user or client to solve a business problem or achieve a business activity, and they are tied to the needs of business, rather than the constraints imposed by technology. This means that the business analyst’s job has more to do with identifying the desired results than the actions or resources required to reach these results. The purpose of gathering requirements is to provide an understanding of the problem or opportunity before trying to propose the solution.

Competency #2: Creating the Business Requirements Document A Business Requirements Document (BRD) is an exhaustive, written study of all facets of regulatory, business, user, functional or non-functional requirements. It is a detailed profile of primary and secondary users and comes directly from the requirements the business analyst has already gathered. It only makes sense, then, that the BRD should be written by the business analyst. After the document is completed, the business analyst and the client, or user, meet for a formal review and to formally approve the BRD. The document is then shared with the rest of the development team, including the project manager. In creating the BRD, a business analyst should define the various sources for requirements and the placement and relevancy of these requirements.

The Essential Business Analysis Skills• Analyze & solve problems• Understand the business• Communicate effectively (write & speak)• Manage client relationships• Facilitate discussions• Negotiate & build consensus• Model data & processes• Plan & manage activities• Facilitate & develop business strategy• Understand & manage organizational change

For example, senior business analysts may identify such items as the project charter and vision, business case, requirements work plan, vendor request documents and business contract documents. They may also work with the project manager to define the project and product scope. Any requested changes to any area of the BRD, before or after work has begun, must be carefully reviewed by the business analyst who would then work with the client or user to make the necessary changes.

Competency #3: Modeling Modeling refers to the ability to conduct structured analysis. In business analysis, modeling is used to support and enhance text-based requirements, help identify and validate requirements, document and communicate requirements and, finally, organize information into coherent ideas. The most common types of business analysis models include business models, process models, data models and workflow models. Experienced business analysts develop models such as business interaction charts or entity relationship diagrams and examine how the business process works now, in order to develop improved charts and help troubleshoot in the future. When looking at models, the business analyst is looking for problems and opportunities that will change the process or the deliverable.

Competency #4: Object-Oriented Analysis An object model is an abstract representation of the process and data requirements of a system, based on separating the system into units called objects. Each object includes the data and operational characteristics of one business item. Object-oriented analysis is particularly important to business analysts as a business planning tool to depict the hierarchy of business functions, processes and sub-processes within an organization. Generally speaking, individuals working on object-oriented analysis should be competent in structured analysis.Object-oriented analysis requires a clear understanding of both the process and data modeling techniques, including the ability to separate systems into objects. Junior business analysts may get involved in the functional separation of the as-is state of a project, including forming a simple model of this state. From this model, an intermediate business analyst may consider developing activity diagrams to further clarify requirements. With diagrams in hand, a senior business analyst is likely to begin designing the to-be state during one-on-one interviews, group interviews and the documentation process. Essentially, each of the processes involved in object-oriented modeling ensures that the requirements are properly communicated to the developers and administrators.

Competency #5: Testing When it comes to testing in business analysis, the first thing to understand is that the term applies to several different levels of work. First, business analysts are looking to test the products to validate whether the requirements have been met. They develop test scripts, test plans and test scenarios based on the as-is state as well as the to-be models. Testing requirements should be done in recurring stages to ensure that, by following the requirements, the desired deliverables will be met. The second level of testing is more familiar. This is testing the functionality of the physical product – testing lines of code and user testing of graphical appeal, speed and functionality. Black box testing and glass box testing fall into this category. As with the first type of testing, this testing also makes sure we reach the desired state, but it is based on user acceptance. In testing situations, business analysts design test cases and review the results from these scenarios.

Competency #6: End-User Support It’s a common misconception among project teams that the project ends when the deliverable is completed. This isn’t true. Business analysts should be aware that end-user support after the product is delivered is almost as important. The role of the business analyst is not to act on behalf of the training team, but to complement the training team’s efforts with their knowledge of the business requirements. Much of the documentation created in the process of identifying the deliverables is invaluable to the development of training needs and end user support, including user manuals and reference materials. Business analysts work with end-users after deployment to clarify any high-level questions that need to be addressed. They also work closely with training managers and facilitators to define requirements to deliver the training supporting the business needs. Finally, business analysts assess and evaluate all feedback from team members, those individuals involved in the deployment of the product and any pilot or “test” groups, to ensure that the requirements necessary to correct any issues are addressed in future releases, iterations or versions of the product.

Competency #7: IT Fluency How much IT knowledge is enough for a business analyst? The IT background for a competent business analyst depends entirely on the environment and possibly the industry vertical within which he or she works. It’s important to remember that IT fluency is just one of eight competencies that a successful business analyst must have. Also, just because an individual is fluent in a given technology does not automatically qualify him or her as a business analyst. This is a mistake made by many organizations. In theory, a great business analyst should have the wherewithal to understand which resources would be appropriate to help define and validate both requirements and specifications within a given project and product scope. In examining the different stages of a business analyst, a person at the junior level would need to have a clear understanding of the IT products and tools necessary for the business to function. An intermediate business analyst may understand interconnectivity and relationships between the tools and, perhaps, system architecture and information architecture. A senior business analyst will demonstrate his or her IT fluency across an industry vertical. He or she may also have a very clear understanding of how different IT products are related, interface with and connect to each other, as well as the positive or negative impact they may have in a given situation.

Competency #8: Business Process Re-Engineering Considered the “big-picture thinking” of business analysis, Business Process Re-engineering (BPR) is a rapidly growing part of business analysis. In fact, lately many companies have been grouping business analysts around this specialty and developing teams of process analysts. This is the phase in which business analysts seek out both problems and opportunities. BPR uses a variety of modeling techniques in order to look at the bigger picture, while still thinking tactically. Business analysts’ responsibilities are often to identify, using various modeling techniques, possible areas of improvement to walk the client or user through each step of the process, examining individual tasks that could potentially be improved and then to actually make suggestions for improvements.

You’ve Defined the Competencies . . . What Next? Now that the competencies have been spelled out, how do companies go about developing business analysts? First, they must develop and document specific job functions, and the task or tasks related to a particular level of competency. Next, they should assess existing knowledge. Finally, they must provide the training needed to develop the competencies outlined above. The first step in ensuring that an organization’s business analysts have the knowledge, skills and abilities necessary for success is to develop job functions, associated tasks and activities, and expected inputs and outputs, that would in turn support an organizations defined competency. When job descriptions have been determined and approved, it’s essential that organizations “take inventory” of the competencies their business analysts already possess. There are specific assessments to test these competencies. Such tools will establish the knowledge level of individuals in each competency area and of the team as a whole. If knowledge isn’t base-lined, improved cannot be observed, and overall performance for the individual and the organization. After establishing the business analysis knowledge and ability levels within an organization, the next step is to implement training to improve any competencies that may be lacking. The competencies above can also serve as a validation tool for such training. They can be used to ensure that the performance improvement program is comprehensive, that no behaviors or competencies are missed, through proper training, on the job experience as well as the appropriate coaching and mentoring. Keeping in mind the eight competencies, as well as the necessary people, processes, tools and technology, will put an organization on the path to better business analysis and, ultimately, to more successful projects.

Building a BA Centre of Excellence.

Written by Glenn R. Brule on February 21, 2007. Posted in Articles.

Where to Start and What to Consider
It strikes me as odd that, given the number of clients I have dealt with over the years, there remains a constant assumption that, because you provide training to a group of individuals in any given organization, you, by right of passage, become a “mature” practicing organization. Get them together on an individual basis, however, and any one of them would tell you quite the opposite. Disarray is perhaps the most fitting descriptor for this case.
We are always willing to acknowledge that which we continuously seek, industry standards. Sadly such industry standards are nowhere near where we want them to be. Take, for example, the Chaos Report developed by the Standish group. It maintains that, of all the projects it assesses in North America, only 34% of them would expect to finish on time, on budget and within the original scope defined. ESI clients have shared with us in a recent survey the fact that the number one challenge in turning requirements into deliverables is poor requirements definition, followed by improper risk management and finally, scope creep.

Why are our projects in a state of disarray? It’s likely not the project management practice. Most organizations have a well-defined PMO and all the disciplines have been identified to conduct their day-to-day activities. It is business analysis and the lack of structure, discipline and rigor around its day-to-day activities that, I believe, is the traceable root cause of project distress.

It’s the situations where we have no formalized process for eliciting, analyzing, documenting, validating/testing, and tracking our requirements. I’ve seen it time and time again where great degrees and variations of the above exist. Organizations have 47 flavors of Business Requirements Document templates and they call this a standard. Their corporate solution development lifecycle gets hacked down, expanded, massaged, and tailored to meet a particular business unit’s need, and again we call this a standard. Methodologies are adopted and then tailored or crafted according to need or thought de jour!

Another area of weakness: how can our resources possibly be expected to deliver with any degree of accuracy if we are not even clear on the tasks and activities that need to be performed to achieve the desired results? Even more seriously, there is no linkage to our “standard methodologies.” As such, we insist on sprinkling the “magic fairy dust” over unsuspecting subject matter experts, and with a mighty push out the door in the direction of our stakeholders, who “don’t know what they don’t know,” expect them to achieve great results. Tell me that’s not a problem waiting to happen! The other very interesting situation that continues to present itself where competencies and career definition are concerned, is that organizations continuously expect that PMs and BAs can perform each other’s given tasks. Our resources are stressed out, and being asked to do more with less, in a shorter period of time. Clearly this need for speed is not working in our favor.

It’s interesting to note that, while we would all acknowledge and recognize the errors of our ways, the real error is not being able to identify a starting point from which we can begin the process of maturing our BA practice. In a world where our daily activities are under constant scrutiny, I find myself repeating an old Japanese proverb “vision without action is a daydream and action with vision is a nightmare!” The question still remains: where do we start?

Three things must be considered. 1) Have a plan, 2) Be patient and 3) Know your capabilities. To have a plan, a project plan, means that, to some degree, you have considered the scope of what it is you and your team are about to embark upon. You clearly understand the major tasks and deliverables, and the time frame in which to accomplish such goals. Tactically, all tasks and activities that need to be accomplished to fulfill the needs of a developing Center of Excellence (COE) are easy to accomplish. Strategically, a cultural shift will not happen overnight, as a change in business practice must be carefully nurtured over a period of time, so we must be patient. Knowing your capabilities will allow you to understand the scope of what it is you are about to undertake. Being honest about the true level of maturity will allow the sponsoring organization to focus on the priority issues. Not all problems can be solved at once, even using advanced “technologies, thoughts and process.” For example, if it is understood that your organization is in its BA development infancy stage, why apply the most complex formulas to begin your baseline metrics. You must walk before you run.

Any good project manager or business analyst will tell you that, without active support, input and feedback, your initiative may be all for naught. Consider your stakeholders with thoroughness.

The Executive Team: The strategic decision makers
Executive Sponsor: May or may not be the same individual or individuals, but essentially hold the budgetary and resource means by which you will accomplish your endeavour
BA Director/Manager or Supervisor: This individual will serve as the liaison between the tactical and strategic sides of the endeavour; they will be ultimately responsible for managing and maintaining the COE.
BAs: Get them involved! Give them a sense of ownership; have them solve some of the challenges facing the organization; select a team of champions that represent the diversity of the BA group. After all they will be on the frontlines!
Project Managers: Without requirements there are no deliverables. Without deliverables requirements have no meaning. This is a mutually exclusive relationship, and should be treated as such. Not including the project managers will encourage a siloed/ independent approach to the delivery of projects and alienate team members. Also consider that much of the structure and foundation of how PMOs evolved can be used as lessons learned for the development of a BA COE.
Functional Managers: There will come a time when the COE will have to engage the functional managers to provide additional resources for the definition and creation of requirements. As such, the borrowing of resources should not be impeded by a misunderstanding or lack of knowledge of what the COE’s purpose is.
Customers: Frequently, customers can be heard complaining about analysis paralysis, and are more focused on the outcome rather than the process used to get there. It is the lack of knowledge and appreciation of this that is important to share with clients. Their feedback and assessment of the performance of the COE will be critical to its growth.

Have a plan, be patient and know your capabilities.

Levels of Maturity: Ask any organization and fifty percent of the time they tell you flat out that they are mature in their BA practices. They tell you they have three standard methodologies, and did some training, “our people are very competent” and, therefore they are operating at a Center of Excellence capacity. The reality is this: while it may be true that investments are made to develop resources and put into place tools and methodologies this by itself does not constitute excellence. The sum of all parts and the practice of organized and disciplined business analysis over a period of time constitutes maturity. For the sake of this article, I have defined three possible levels of BA maturity. The titles themselves are arbitrary and may be changed according to the requirements of the sponsoring organization. It is the classification and characteristics of each level of maturity that will provide the needed assessment and guidance for development.

Level I – Community of Practice

Most organizations today are performing business analysis at a community of practice level. They have recognized the need to develop the skill sets of their BA resources, and may have even gone as far as doing an assessment and evaluation of the level of competency of their BA group. As such they were able to identify any gaps that might exist in both performance and overall competencies and job descriptions. Other organizations have also begun to put into place a solution development lifecycle and are likely to be in the process of either redefining or developing one. A common question that comes up is this; what do we develop first, the people or the processes? My response is go with the egg, eventually the chicken will come! The processes need to define what needs to be done, and how it will be done, in the context of an SDLC. Job descriptions must define the ability, skill and knowledge necessary to perform the tasks and activities defined in the SDLC. The solution development lifecycle and job descriptions/career paths and competencies must be closely interrelated. They may begin to demonstrate an alignment with the PMO.

An overall acknowledgement by the organization of the role of the business analyst and its importance to the success of overall project deliverables is beginning to form. At this point our services, if sought, perceived as being reactive in response to an immediate need, and generally sought after as a utility. At this point, our accomplishments are only beginning to have any real recognition at the middle management level because of the tactical nature of our services.

Level II – BA Bureau of Maturity

There is no doubt in my mind that many organizations have demonstrated in some capacity their level of maturity given a specific area with the guiding principles in level of maturity. They may include some of or all of the following items, but in order to move from one degree of maturity to another demonstration of the following with consistency over a period of time is necessary. A direct reporting structure to either the PMO or the CIO may be in place a Director of the BAB is likely to be the leader of the BAs and as such is making strides to present his team as a distinct business unit. The team is clearly a distinct pool of resources. From a services perspective they are beginning to show signs of credibility amongst the business unit leaders as a result of consistent performance excellence. Business Unit Leaders are seeking out the team to provide assistance when needed, and the recognition of moving from a tactical to strategic role is beginning to form.

Level II – Center of Excellence

You’ve developed partnerships with the executive. Your team is sought after as the change leaders of the organization. You are clearly recognized as a customer service solution. You and your team have demonstrated your discipline both tactically and strategically. Most importantly, you have clearly defined the art of Enterprise Analysis (EA) and demonstrated your ability in the five areas of EA including, Business Architecture, Information Architecture, Application Architecture, Technology Architecture, and Security Architecture. Your team is providing and sponsoring studies to participate in overall corporate advanced and BPI & KPI’s and overall business effectiveness. Your continuous assessment and evaluation of performance on internal process and customer satisfaction has become commonplace.

There are two keys to clearly understanding your level of maturity with the presented model. Acknowledge that it is likely that your organization may demonstrate maturity at a variety of levels given this framework. Also consider that true excellence must be demonstrated and evaluated as consistent over a period of time. As an example, training may be delivered in order to move the organization into a Community of Practice / level one of maturity. Training and learning do not stop here. Certification, coaching and mentoring, participation in improvement initiatives, and membership in organizations such as the IIBA, are the contributing factors that move an organization from one level of maturity to the next. In short, the sum of the parts is equal to the whole!

Glenn Brûlé, Director of Client Solutions for ESI International, has more than 15 years experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. Glenn’s background as an educator, communicator and business consultant has served him well through his many client engagements that have focused on understanding, diagnosing and providing workable business solutions to complex problems.In addition to his position at ESI, Glenn serves as a Director at Large for the International Institute of Business Analysis (IIBA). His primary responsibility is to form local chapters of the IIBA around the world by working with volunteers from organizations across various industries and government agencies. Glenn has successfully launched eight chapters in major Canadian cities and is currently working on launching eight more U.S. chapters and nine outside of North America. Glenn Brûlé is a frequent speaker at professional association meetings and conferences around the world, including ProjectWorld/World, Congress for Business Analysts and IIBA events. He has authored numerous articles on business analysis and was instrumental in the development of ESI’s white paper titled “Eight Things Your Business Analysts Need to Know – A Practical Approach to Building and Improving Competencies.”

Watermark Learning Reports Increased Demand for Business Analysis Training

As awareness grows in the project management industry, demand is increasing for business analysis training, since business analysis is frequently cited as a key problem area for providing inconsistent deliverables. As a result, companies such as Allianz Life have established a Business Analyst Center of Practice to ensure that their business analysts have the framework, processes, skills and techniques to excel in their profession.

“In today’s competitive landscape, businesses must perform with razor sharp efficiency and productivity,” said Terri Swanson, Watermark Learning, COO. “More business leaders are recognizing the value that business analysis training brings to an employee’s contribution and the effectiveness of an organization as a whole.”

Since launching the Masters Certificate in Business Analysis in July 2005, Watermark Learning has received hundreds of participants in the program, including Allianz Life, a life insurance company.

Allianz Life identified the business analysis process as their key problem area providing inconsistent deliverables. They established a Business Analyst Center of Practice to ensure that their business analysts had the framework, processes, skills and techniques to excel in their profession. As part of this initiative, Allianz Life looked to partner with a training vendor who could provide a professional business analysis certification program based on industry best practices, designed to specifically address their business needs.

“Allianz Life engaged Watermark Learning for training because of its Masters Certificate Program in Business Analysis as well as its practical learning approach based on best practices,” said Lynn Lang, Allianz Life. “Not only will our business analysts receive a Masters Certificate, but they will also gain Professional Development Units through PMI as well as CEUs through Auburn University.”

Watermark Learning is actively involved in raising industry awareness of the value of business analysis and was named an IIBA Endorsed Education Provider. It’s principals and founders, Elizabeth Larson, PMP, and Richard Larson, PMP, have helped develop the Business Analysis Body of Knowledge (BABOK), a document created to identify the key tasks that a business analyst would be expected to understand and perform