Skip to main content

Tag: Best Practices

Back to Basics and a Look to the Future

PW08Crowd_300x139.png

9:50 AM
Wednesday, April 16th, 2008

ProjectWorld * BusinessAnalystWorld
Toronto 2008

Thank you for being part of this!

To view a slideshow of photos from the 2008 Toronto event, click here.

It’s been a hectic couple of weeks with ProjectWorld * BusinessAnalystWorld in Toronto in mid-April and Project Summit & BusinessAnalystWorld in Philadelphia this week. But it has been an enjoyable couple of weeks meeting new and old associates, hearing great speakers and being exposed to exciting new ideas.

And we have another exciting Business Analyst Times for you. Glenn Brûlé continues his Back to Basic series with episode two, Second Fundamental: Creating a Common Vocabulary, in which he discusses the old bugbear – communication and the positive or negative impact it can have on the project. Robert Wysocki wonders if it might be worth considering merging the BA and PM functions into one. Always sure to make people sit up, he puts forward his ideas in Is it Time for the BA and the PM to Get Hitched? Sandra Lavoy looks at what it takes to retain good IT people and Natasha Terk revisits the subject of e-mail with Ten Tips for Writing Effective E-mail Messages.

Our bloggers are back in fine form with their distinctive views – and not always agreeing! Check them out and take sides or sit on the fence. Either way, let us know what you think.

Best Regards, 

Adam R. Kahn
Publisher, Business Analyst Times
[email protected]

Getting Back To Basics

First Fundamental: Understanding Overall Business Goals

I have noticed themes emerge during each of the last few years, which I believe embodied overall trends during the year.  For 2008, I believe “getting back to basics” is a theme that deserves great attention and consideration.  With the tremendous growth in both the acknowledgment and the embrace of the profession of business analysis, it’s hard not to imagine BAs being simply overwhelmed by the vastness of information that exists. Returning to the foundational principles of business analysis will make the vastness more navigable.

In a Google search of business analysis, the results weighed in with an impressive 73,300,000 hits. With all that information out there, where does one begin trying to understand how he or she might be successful in practicing even reasonably good business analysis techniques?  Returning to the fundamentals will enable you to utilize a kind of Occam’s Razor, or law of economy, in your technique.  Occam’s Razor is a principle originated in medieval times, and still used today, which states that entities should not be multiplied beyond necessity.  In other words; the simpler the better. 

There are five key fundamentals that will enable you to wield your own Occam’s Razor and derive great requirements: 

  1. Understand the overall business goals and the desire to build a solution that meets them
  2. Create a common understanding of “vocabulary” to be shared by all
  3. Identify the sources from which you will extract your requirements
  4. Understand which elicitation technique is most appropriate, considering your resources
  5. Understand – with absolute clarity –  what modeling techniques are most appropriate, given the solution(s) to be designed

This article will focus on the first fundamental. Successive articles will expand on the remaining four areas that must be practiced time and again on any BA development and management opportunity.

Be Clear On The Vision

So very often I have had the opportunity to parachute into a project where the requirements development process is well underway or about to get underway. Sadly, in the majority of cases, when I ask team members what the overall vision is for what they are doing, they are unable to answer this fundamental question. Without a common understanding of your destination, how can you and the rest of your team members be clear or confident on what directions you are to take in identifying stakeholders and defining, developing and even managing the requirements process?  No matter how large, how small or how urgently the client “has to have this,” creating a vision statement provides a map, and the BA is the compass that guides the organization in following the map. 

It isn’t my recommendation to write a lengthy vision statement; quality rules, not quantity.  In order to accurately define a vision statement for the project that you are about to begin or are currently adrift in, a simple question may prove to be the guiding light: “Is what we are doing adding value to the organization in that it supports the organization’s overall business goals, values, vision or mission?”

If you or any of your team members cannot answer this question in a short and concise manner, your project is at risk.

Some basic steps can be taken to correct the navigation instrument that will guide you to your destination.  Simply stated, the vision answers the who, what, why, when, where and how of what you are about to embark upon.  Consider this: if you were to get in an elevator at the lobby level and the executive sponsor were with you, could you accurately describe to him or her in one minute or less what it is that you are working on?  That’s right-a vision statement is your “elevator” speech, but from a business point of view.

There is no question that this will often evolve into a project charter or form the basis from which you will continue to refine your business case.  This is the starting point and will continue to provide input into other areas of your project, so above all, be clear on what you will include in your vision statement.  Here are some guidelines that I recommend:

  1. Clearly articulate the reason(s) that stakeholders are seeking to develop a solution
  2. Identify who the consumers of this solution will be
  3. Determine if the solution supports the overall business goals and objectives

Facilitating Consensus Among Stakeholders

If you are clear about the above process, then a facilitated session with key stakeholders and the executive sponsor with the intent of verifying these guiding statements should prove to be a relatively easy task.  Have the group identify the following:

  1. Why is there a need for a particular project?  Are we solving a problem?  Taking advantage of an opportunity?
  2. Who are the consumers of the end result (external customers, internal users, etc.)?
  3. What benefits will the organization realize and the consumer of the solution realize? Can we quantify those benefits?
  4. What is the nature of the solution?  Is it an improvement to an existing system or process? Are we in the hunt for a new product or service? Are we taking on the implementation of a complex system?
  5. If it is a service we are going to offer, will it be competitive or allow our organization to remain competitive in the marketplace?  Will it be a unique offering or service that consumers will actually want or use?

All of these questions can be answered using a variety of facilitation techniques, including

  • Brainstorming, or the nominal group technique
  • Requirements identification
  • Requirements prioritization
  • Consensus building
  • Workshops
  • Gap analysis

Prioritize the results if necessary but, above everything else, be certain that all the stakeholders come to a consensus on the vision statement and that it aligns with the overall business objectives and goals.  Using the steps outlined, one should be able to derive a vision statement. The following example is a vision statement for the development of a travel and expense management solution:

Any individual or business unit  that incurs expenses will immediately realize that automating such things as credit card downloads, approval chains, assigning GL codes, and converting foreign currencies will improve the speed and efficiency with which reports can be written and approved. Unlike the conventional and cumbersome means of filling in a spreadsheet, a Web-based product will not only provide the convenience of accessibility, but will also prove to be a great tool for auditing and evaluating types of expenses incurred, and negotiating travel expenditures with respective vendors.

The Three Ls of Business Analysis

I’m sure you’ve heard the three Ls of real estate:  location, location, location.  It’s the overriding, fundamental principal that every realtor knows.  For BAs, the word (and function) “quantify” is our equivalent mantra.  Here’s the best part about quantifying your findings: it’s empowering. 

Too often BAs abdicate their true role and become order takers.  Quantifying your findings will restore your true role as an objective advisor.  It takes the burden from you of being the bearer of bad news, since the numbers-the expected ROI or Internal Rate of Return (IRR), the amount and value of resources required, the deliverables-speak for themselves.  Quantifying the potential outcome will make the case for either assuredly moving forward or knowing that a project or program is not feasible. 

Take, for example, a retailer whose mission is to be number one in sales in their market.  Does it mean they are going to source the merchandise they sell or manufacture their own as well?  The BA’s role is to provide quantification to demonstrate outcomes for both sourcing and manufacturing options. Eliciting proper requirements is critical at this stage to determine, among other needs, what the target market should be, who the customers are, who is responsible for implementation and product development in its entirety.  

The Fundamental Edge

In a favorite quote of mine by John F. Kennedy, he said, “There are risks and costs to a program of action. But they are far less than the long-range risks and costs of comfortable inaction.”  Heady stuff, but it certainly applies when the success or failure of a business or organization is at stake. 

Time and time again I have witnessed client/customer pressures to produce quality services, and the effects that these pressures have had on a project team and BAs due to “cutting corners” in order to meet these demands.  Failure to get back to basics will result in increased risk, decreased quality and budgets that amount to, or exceed, the number of hits that Google produces when you perform a search for business analysis!

These are just a few of the risks BAs face as they perform their jobs.  However, deploying the fundamentals will ensure that you provide your best counsel for the organization’s success.

This is the first in a five part series of articles by Glenn Brûlé.


Glenn R. Brûlé has more than 18 years experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI (www.esi-intl.com), he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. As the Director at Large for the International Institute of Business Analysis (IIBA), Brûlé’s primary responsibility is to form local chapters of the IIBA around the world by working with volunteers from organizations across various industries, including financial services, manufacturing, pharmaceutical, insurance and automotive, as well as government agencies.

Show Me The Money

Last month we posed a quiz, as we continue to build robust requirements for a National and Global Identity System. We “hid money” in this quiz, and now we’re going to try to find it! Here is the list of stakeholders we gave last month:

Citizens

Businesses

  • Banks
  • Credit Card Companies
  • On-Line Sellers
  • Airlines
  • Hotels
  • Disney (takes fingerprints, did you know?).
  • Retailers
  • More along the same lines….

Government

  • Law Enforcement
  • National Security
  • Immigration
  • Customs
  • Internal Revenue
  • Labor Department
  • Unemployment Agency
  • More along the same lines…
  1. What might be wrong with the above list? First – note that it is not only citizens with a stake, but all individuals. If you were being arrested, how would you feel if the police identified you improperly? If you are an illegal alien, you still need to work (and we need you). What is to be done? Second – what about non-business, non-government institutions? Are non-profits different? Are some organizations not even characterizable simply as non-profit? Third – identifying individuals, businesses, governments and other institutions may not be sufficient. Do all stakeholders have the same needs and goals? Are there categories based on identity “needs” more useful than the institutional ones we have chosen? How is local law enforcement different from homeland (I hate that word) security or immigration?
  2. What might it cost to ignore the errors/omissions/assumptions, if any? We know the answer to this, because existing ID systems have NOT identified and addressed all stakeholders and their needs. The cost is exactly the situation we have now – a world of rampant identity theft (1 in 20 may be affected each year), in which law enforcement is almost powerless, a world of unjust convictions and misuse of DNA evidence, a world of constant privacy violation with little or no recourse (the price of fame is constant media pecking, a disincentive to achievement).
  3. What concepts or categories might help with analyzing this list, regardless of any problems so far? Identity needs for criminal convictions are different from those for purchases, for charitable giving, attendance at private social events, and hiring a handyman, etc.
  4. If you, as a BA, can even begin to address such questions, what is your earning potential? I can only speak for myself – since realizing what I was capable of, and getting my CBAP so others would know too, my income is now well into six figures, and my ability to get work and promotions is vastly improved. How are you coming along?

FOR NEXT MONTH:

To reassure ourselves that we REALLY understand the stakeholders, we will try to list the “identity transactions” that might occur in society, and we will try to match these transactions to the kinds of stakeholders we are aware of so far (individuals, businesses, government, and other organizations).

 How many identity transactions can you think of, or how would you elicit such a list?

Potential answers will be discussed next month, and incorporated into the case study. The best reader response will be acknowledged next month (send a picture with your response!) and will undoubtedly receive a large raise in the near future, just for rising above the pack!

How to Become (or Manage) a Successful Business Analyst

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 SkillsAnalyze & solve problemsUnderstand the businessCommunicate effectively (write & speak)Manage client relationshipsFacilitate discussionsNegotiate & build consensusModel data & processesPlan & manage activitiesFacilitate & develop business strategyUnderstand & 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.