Tag: Best Practices

The Business Analyst Commandments

Written by Tim Ward on January 24, 2012. Posted in Articles. 1 Comment on The Business Analyst Commandments

Eliminate ambiguity. If you can arrive at more than one understanding or conclusion, chances are so can a developer or tester.
When using terminology, don’t assume everyone has the same understanding. Get immediate confirmation to avoid misunderstandings. A glossary of terms and related aliases are very helpful.
Promote “plainspeak”, the use of common (English) language when describing business facts, rules, regulations, processes, data, etc. If it is necessary to document something in business or IT jargon then paraphrase its true meaning in plain English.
When business or IT terms are used to describe something, always confirm the definition (e.g., when we say “transfer” we mean …).
Don’t ask for permission, ask for forgiveness.
Understand cultural differences within or between business organization entities and IT. It will help in following other commandments.
Requirements should describe what something isn’t as well as what it is.
When eliciting requirements, ask clarifying questions to confirm the requirements are being clearly captured.
When eliciting requirements, it is important to identify the audience affected (e.g., line of business, products, plan types, etc.).
When documenting requirements, decisions or issue resolutions, it is equally important to document the “why” as much as the “who”, “what”, “when”, “where” and “how”. If you don’t, it is more likely that no one will remember later why we went down a certain path.
When defining requirements, remember that it has to be testable. If you can’t adequately test it then the requirement is not adequately defined.
There are no assumptions, only a current understanding of the facts. Use of assumptions only promotes growth of undesirable anatomical features.
When writing (or speaking), put yourself in the reader’s (or listener’s) shoes. Would they really understand what I’m trying to convey based solely on the words I’ve written or spoken? Is there an unrealized expectation that they audience has some level of implicit knowledge in order to understand the subject matter?
Treat your developers and technical support staff as you would like to be treated: as a trusted ally and good friend.
Understand that people requiring your services as a BA don’t always know what they want and/or are unable to effectively articulate their needs. That’s why God invented BAs.
As a trusted subject matter expert, people will usually believe what you say as fact, especially if you are good at clear communication. Being in this position of trust, there is an inherent risk that sometimes you may be wrong in your understanding (and are unaware[RC1] ). However, you are persuasive enough to convince everyone of this truth. You need to rely on others to be able to detect the conveyance of false truths before it’s too late.

Don’t forget to leave your comments below

Tim Ward is a Business Analyst with over 30 years of experience in the financial services market dealing with group retirement plans. He is also a member of the IIBA and received his CBAP certification in 2009.

7 Trends in Business Analysis and Project Management to Watch for in 2012

Written by Elizabeth Larson on January 10, 2012. Posted in Articles.

The close of one year tends to make one reflect on what has occurred in the past year related to and ponder the future. Here we ponder some trends in the Project Management and Business Analysis fields for 2012. Here are our top seven predictions for business analysts (BAs) and project managers (PMs) in 2012.

Divergence of the PM and BA Role. In 2009 we predicted that as the economy tightened, organizations would decrease their project budgets and combine the role of PM and BA. For 2012 we believe that organizations will see the need for both roles, particularly on strategic projects, and move away from a combined role. There are several factors for this trend:
1. Business analysis is maturing as a profession. As the IIBA has gained traction, more organizations have become aware of the BA role and its importance. From 2010 to 2011 the number of IIBA members increased about 50%.
2. Organizations have found that even with successful project management, many projects fail because of dissatisfaction with the end product. Having business analysts helps ensure that the product is a solution that works and is one the organization needs.
3. PMI has recognized the importance of the business analyst role. In 2010 they undertook a study to determine areas of overlap, handoffs, and how the two roles could collaborate.

Combined Agile methods. We predict that Agile methods will continue to change and merge as organizations take advantage of the benefits of Agile. In our 2009 Trends blog we stated that “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.”

In the two years since we wrote that article, Agile methods have continued to evolve. Although organizations have widely adopted Scrum as the predominant Agile method, they still struggle with its implementation. We think that organizations will continue to adopt Agile methods, but that these methods will continue to evolve. Combined techniques, such as Scrum-ban (which combines Scrum with the Lean technique Kanban) or Scrumerfall (a combination of Scrum and Waterfall) will be adopted for different kinds of projects.

PM and BA on Agile projects. We predict that the role of the BA and PM on Agile projects will solidify. When Agile started to be adopted, some organizations thought that the roles of PM and BA were obsolete. However, more and more organizations have recognized that the need for both roles, even if the titles are new. The Scrum Master role is best filled by someone with the expertise to coordinate the initiating, planning, executing, monitoring, & controlling, and closing each iteration and release. In other words, the work typically done by a PM. The designations of Certified Scrum Master (CSM) from the Scrum Alliance and Agile Certified Professional (ACP) from PMI have solidified this role.
The role of the BA on an Agile project has not solidified. BAs are used in a variety of ways or not at all on Agile projects. There have been heated discussions on LinkedIn discussion groups and at conferences about this role. While many organizations use BAs in the product owner role, the fundamental issue of the product owner having to make business decisions makes this problematic. Going against most of the current thinking, we predict that organizations will realize in the next few years that business analysis is essential to Agile projects. Agile projects still have requirements, and there is a need to go from high-level user stories to the detail needed to develop the needed functionality. Organizations will realize that this in-depth analysis cannot be completed during an iteration, that it has to happen just prior to development. This is called grooming the product backlog and is the perfect role for the business analyst.

The BA as management consultant. We predict that in 2012 BAs will actually function as described in the BABOK® Guide, version 2.0. That is, more BAs will “recommend solutions that help the organization achieve its goals.” They will do that in a variety of ways:
1. Business cases. More organizations will recognize that the BA is in the best position to develop business cases. Although often performed by PMs, this function happens prior to the initiation of a project and is input to project initiation (PMBOK® Guide – Fourth Edition). The PMBOK recognizes that the performing organization (business owner) is accountable for the business case, but it is the BA who is in the best position of developing it.
2. Ability to Influence without Authority. We are seeing more organizations tell us that they want their BAs to move away from taking customer orders and start using their expertise to recommend solutions. This need correlates to the enthusiasm we have seen around the need to influence without authority.
3. In her keynote at the BBC conference in Ft. Lauderdale last year, Kathleen Barrett, CEO of IIBA mentioned that one of the key competencies of the enterprise BA is management consulting.

BAs as change agents.We think that BAs will be more involved in change management. At the BBC conference in Ft. Lauderdale last year Kathleen Barret announced a new tag line for IIBA—that business analysis was about changing how organizations change. In other words, BAs will be more involved in change management. Changes might include changes in business processes, job descriptions, reporting structures, software, and more. Here are some of the ways we see this happening:
1. Enterprise analysis. Before projects are initiated, BAs determine the business need across the enterprise and recommend solutions, which need to include the ways in which organizations will need to change when these solutions are implemented.
2. Project work. While the identified at the enterprise level are by necessity high-level, the changes resulting from each project will be specific in nature. We predict that BAs will develop better tools for assessing whether or not the organization is ready for the change. We think that they will act as management consultants once the project has been defined to ease the pain associated with implementing the changes associated as with implementing the solution.
3. Post-project follow-up. We believe that BAs will be called on to monitor the post-implementation changes and continue to consult with the organization on the best way to make the solution work, even when there is some organizational resistance to it.

The virtual environment.Now that it is here, the virtual environment will continue to flourish, even if the economy improves. There are a variety of reasons why organizations will continue to rely on the virtual environment for completing projects, for training, and for webinars to replace live conferences.
1. Travel budgets. Spurred by a sluggish world economy, many organizations have reduced travel budgets for team meetings, training, and international conferences, relying instead on the virtual environment. Although colocation of teams is ideal and preferred, it is not always possible. More teams communicate and collaborate virtually, more virtual training will occur, and more webinars will take the place of live conferences.
2. Globalization has made travel impractical. Although face-to-face time, particularly during project initiation, is helpful in building trust, respect, and relationships, it is not possible to be together for all project meetings and/or requirements elicitation interviews and workshops when the team is located across the county or world.
3. Collaboration tools have made the virtual environment not only possible, but practical. Net meetings, as well as more robust training and webinar tools have supported virtual teams, so that real work can be accomplished. In addition, teams have learned how to build relationships and trust in the virtual environment. Building relationships and trust in a virtual environment is easier and quicker once people accept and feel comfortable with the virtual tools available.

“The economy, stupid,” a past political slogan said. During a slumping economy, organizations look of ways to maximize efficiencies. Focus turns to business processes and how to improve and manage them. During more prosperous times, interest in business process management tends to wane. We predict that business process management, with an emphasis on eliminating waste in organizations, will continue throughout 2012, even as the economy (hopefully) shows signs of improvement. We also predict that there will be no dominant tools for managing processes and recommend that project professionals doing business process work focus on core concepts and skills and be flexible when it comes to using BPM tools.

Don’t forget to leave your comments below.

Elizabeth Larson and Richard Larson are Co-Principals of Watermark Learning, a project management and business analysis training company. They have over 30 years of industry experience each, and have helped thousands of PM and BA practitioners develop new skills.

They have published numerous articles and papers and have co-written two books together on Requirements Management and CBAP Preparation. Both Rich and Elizabeth are CBAP and PMP certified through IIBA and PMI, and are contributors to the BABOK® Guide, Version 2.0 and the PMBOK® Guide – 4^th edition.

Open-Ended Questions

Written by Karl Wiegers on January 3, 2012. Posted in Articles.

The Business Analyst as Explorer, Part 5 of 6 by Karl Wiegers

An effective business analyst is not simply a scribe who records whatever customers say. The BA needs to stimulate the thinking of the people he’s interviewing to get below the surface. The BA should ask questions such as “What else could happen that we haven’t already discussed?” and “Would anyone ever want to ?” and “Could ever occur?” These are ways to discover possible lower-probability scenarios or options the system should provide to the user.

In their book Exploring Requirements: Quality Before Design, Donald Gause and Gerald Weinberg describe “context-free questions.” In their words, context-free questions “are high-level questions that can be posed early in a project to obtain information about global properties of the design problem and potential solutions. Context-free questions are completely appropriate for any product to be designed….” The BA can use such questions to explore both processes and products. They’re a valuable complement to specific questions about the capabilities and characteristics of the product being specified.

In my experience, requirements elicitation discussions typically emphasize the expected normal behavior of the system. However, anyone who has ever done any programming knows that a good developer writes a lot of code to deal with exception conditions. An important aspect of requirements elicitation is to identify things that could go wrong, determine how the system should detect an error, and describe how the system should respond to the error. As a BA, you need to probe around the exceptions during your requirements discussions. Ask questions such as “What should happen if ?” This is a way to detect missing requirements that haven’t come up in the discussion yet. It’s also a way to surface previously unstated assumptions. Testers are particularly adept at spotting exception conditions, so I like to have someone with testing experience participate in requirements elicitation sessions, if possible. I also engage a tester to review the emerging requirements documentation and look for exceptions and alternatives we haven’t considered.

Beware of asking questions that solicit a yes/no or multiple-choice type of response. Such questions can unnecessarily constrain the answer so that the requirements discussion misses an opportunity to discover (or invent) something that goes beyond the BA’s preconceptions. Of course, this doesn’t mean you can’t ever ask a question with a closed list of possible responses. Just make sure you aren’t prematurely constraining the exploration.

The last question I typically ask in a requirements elicitation discussion is, “Is there anything else I should be asking you?” This is an example of a metaquestion, a question about a question. I freely admit that I don’t know all the right questions to ask. Sometimes the person of whom I’ve asked this question realizes that we haven’t yet discussed some important topic. I simply didn’t know enough to bring it up.

I use this same question in daily life. A few years ago I had new kitchen counters installed in my house. I’d never done any home remodeling before and didn’t know that much about the process. Near the end of my discussion with a contractor, I asked, “Is there anything else I should be asking you about this job?” He thought for a moment and then brought up an issue we had not yet discussed. This is also a collaborative question to ask. It acknowledges that you rely on the expertise of other people to work toward a mutually satisfactory project outcome.

Business analysis is hard! Because it is intrinsically a communication-centric human activity, I don’t know of any shortcuts. Business participants in the requirements elicitation process can get frustrated by the number of questions the BA asks and how long the process can take. But that’s just the way it is. And it’s a whole lot cheaper and less painful to have those discussions before you’ve actually built the software.

Don’t forget to leave your comments below.

Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is a memoir of life lessons titled Pearls from Sand: How Small Encounters Lead to Powerful Lessons.

Rhinestones Look the Same as Diamonds…

Written by Simon Papson on December 6, 2011. Posted in Articles. 2 Comments on Rhinestones Look the Same as Diamonds…

I was recently working on a project team of three: two developers and me. One of the things we had in common was that all three of us are perfectionists (in our various ways).

I noticed this trait in one of the developers early on: every button on every screen that he produced was aligned just so, the fonts were sized just right and the colours were the ideal shade. Similarly, the other developer enjoyed refactoring code just for the sake of making it more elegant; he loved the idea of working on a section of code for hours at a time to reduce it to just a single line. And I, the BA-cum-tester—if a system contained any defect, however small or esoteric, I rooted it out. Corner cases were merely a starting point for me!

This perfectionism led to us deliver absolute diamonds of features; between the three of us, we were producing an utterly perfect system. Which is something to aspire to, isn’t it?

Like every project, we were operating within constraints. In terms of the time-cost-quality project triangle, we were limited in cost and extremely limited in time. The business was desperate for a working version of the system we were developing: last year was too late (no exaggeration!). And, in this context, we were making quality the highest priority.

Luckily, we had a project manager who wasn’t afraid to shake things up when necessary. So, he made us all sit down and assess our performance to identify and fix the problems that were slowing us down. As a result of this exercise, one of the problems we found was our drive for perfection (naturally!).

For example, whenever a story was “developer-done” and passed to me for the first round of user testing, I would put it through its paces and pull it to bits. No defect was too small, no niggle too minor. And, the minute I found a problem, the developers would compete with each other for the chance to fix it. “Zero defects” was our goal!

Some days, we would find ourselves caught in a cycle of UAT – defect finding – defect fixing – UAT – defect finding – etc… with no development being done on new features.

No wonder we were delivering so slowly! Our perfect diamonds of features were being formed over near-geological timescales, just like actual diamonds.

So, we changed, and one of the things we threw out was our commitment to “zero defects.”

Defects were then put through a triage process. Did it stop the system running? Did it cause the system to produce the wrong result? Would it cause difficulties for the users? Would the end customers notice the difference? If yes, then it must be fixed, by all means!

On the other hand, was it just cosmetic? Did it only occur under extremely rare circumstances (just how often do all the planets align in a single line, anyway?)? Could the users still get the right result? Would the customers still receive the right information?

No one was saying that the system should have defects. We merely decided that some defects could be lived with in the short term, in the context of a system that must be delivered in working condition as soon as possible. We could (and would!) fix all defects over time. All we did was prioritize the defects that must be fixed now over those that could be fixed later.

And, if the users don’t notice, and the end customers don’t notice, and the system is fit for purpose, then who’s to tell whether it’s a rhinestone or a diamond? After all, rhinestones look just the same as diamonds… but they cost a lot less.

Don’t forget to leave your comments below.

Simon is a Business Analyst with about 5 years’ direct experience in the BA field, but he’s a spent a lifetime gathering insights in careers as diverse as accounting and pizza delivery – and even acting! He’s worked in both waterfall and Agile environments (and prefers Agile!), in large corporates as well as small businesses. He’s always had the writing bug, too!

Six Common Problems Faced By A Business Analyst

Written by Aruna Parameswaran on October 4, 2011. Posted in Articles.

Usually in an SDLC cycle, the requirements elicitation phase is right at the beginning. As oft repeated, this is a very crucial phase that will make or break the project. This is the only time in the entire SDLC when the business users spend considerable time with the business analysts. Since these are focused sessions or workshops, it is imperative that the business analyst is able to make the most of the business users’ time and knowledge. It is important to remember that there will be no phase in future that provides the BAs with this luxury! However, it is not without its own problem areas.

In this article, I will highlight the most common problems and provide some pointers as to how we can work around them. These may not be foolproof solutions but they will work in most situations. I leave it to the reader to decide.

1. Resistance in sharing information: In some cases, information will not be forthcoming. These users will regularly attend your workshop but it will take a mammoth effort to make them talk. At the other end of the spectrum, there are users who make your life difficult by bombarding you with loads of documents. In such a scenario, even to find the answer to a simple question, you may have to read hundreds of pages!

How to get around this problem:

The very fact that the users are not sharing relevant information should raise red flags. We need to understand the users’ reasons for doing so:

Are they resistant to change and are so used to a certain way of working that they do not want to change?
Is it a complicated case of ego issues and office politics that causes them to not want to share information?
They really don’t know why a certain process is being done in a particular manner and they have been blindly following it for ages.

The first two issues get addressed gradually once the BA is able to gain the users’ confidence and trust. In my experience, this usually happens after a couple of sessions. Once the ice is broken, information flows more easily.

The last issue is a bit tricky as users hate to admit that they never thought of the ‘why’ and they just concentrated on the ‘how’. The BA has to word his or her questions very skillfully here. After playing detective, it is often very clear that users don’t have the information that is the BA needs. Once this is known, the BA will have to identify the proper source for this information by talking to the facilitator.

2. Irregular attendance:

This happens when key users attend one session and then skip a few in a row. Suddenly, they appear and start changing the course by asking/changing things that were frozen during their absence. Or worse still, they want you to start from where they left.
A set of users keeps on rotating, and a user who is present today may be gone tomorrow. There is inconsistency in attending the workshop.

How to get around this problem:

The first problem usually happens when the changes have been proposed by IT and not driven by a business need. Since there is no buy-in from the business users, they are not interested in attending the workshops. However, as the project is be driven from the top, they attend the sessions intermittently to get the ‘attendance’ and ‘participation’ tick mark. They also pose hurdles in the form of the next problem as they send their team members in turns.

As a business analyst, apart from escalation to the project manager and the project sponsor, there is nothing much that can be done. The BA can highlight that the requirements captured during the workshops may have to be re-validated as there is no continuity of the users.

3. Accountability for decisions:

There may be instances in which the current business process needs to be changed or modified to make it more efficient. The users may all be in consensus but none will volunteer to approve it. Or, there could be situations where the elicitation process may reach a dead end if certain decisions are not taken.

How to get around this problem:

The very fact that the users are in consensus is itself a big win. Here, the only issue is of accountability. If the issue under discussion can be moved into a parking lot and can be considered later, then the next function can be picked up. If this is not possible then along with the project manager, the BA can prepare a business case and present it to the user community. The business case document should have enough details for the decision-maker to come to a decision. It should clearly elaborate on the issue on which the decision is sought and the preferred outcome to resolve that issue.

4. Resolving user conflicts:

This could take two forms:

a. Conflict between the business analyst and the users: This usually happens when the business analyst tries to propose a new or a modified approach to the current process that is being followed.

How to get around this problem:

To address the first problem, the BA will have to first understand the resistance from the users. Has he/she missed or not taken something into consideration? Or, is it again a situation where the users wish to continue doing what they have been doing? The BA will first have to get clear answers for these and potentially other questions. After all this is done, if the BA still feels that the recommendation needs to get a user buy-in, then the approach followed will be similar to the one that we saw in the earlier problem area, i.e., preparing a tight business case without any loopholes and presenting it to the users.

b. Conflict between users: If users who perform similar tasks across different organizational functions come together, there is bound to be conflict as each one feels that their approach is best.

How to get around this problem:

This could be an ego issue as each function would like to outshine the other. This is an area where the BA’s facilitation and analytical skills are put to test. The BA should be able to dissect all the views that have been put forth and try to facilitate a healthy discussion in which all the parties are listened to. It is not necessary to accept every suggestion but it is important that each user feels that he or she has been given a fair chance to present his or her case. In most situations, this approach works. If it doesn’t, the only option left is escalation to the relevant people.

5. Real needs vs. perceived needs:

Sometimes it becomes difficult for business users to distinguish between a real need and a perceived need. A perceived need is always a little tricky as it may be a workaround/temporary solution for the problem and not the problem itself!

How to get around this problem:

Real needs are the obvious ones and can be easily identified. These are usually the issues or the major process changes that the business requires. In the eyes of the business user, a perceived need is very much a real need. The trick here is to dig deeper and probe to discover the real issue. For example, a user might ask for the functionality to update data. This can definitely be a risky requirement as it may lead to data tampering. However, the real need may be that the source data is received in an Excel file and the user probably has to do some sort of data formatting (e.g., date to be in mmddyyyy instead of ddmmyyyy) and hence the request. This can be easily achieved by asking the source to provide the data in the requisite format. Thus, it is very important for the business analyst to dig deeper and identify the true problem area.

6. Changing needs:

Time and again, we have faced this, and there is always a dilemma as to whether a BA should accommodate or ignore the change.

How to get around this problem:

This is a perpetual problem and I am sure that there is hardly anyone in the business analyst world who has not faced this! There is no hard and fast rule to accept or reject the changes. The best way is to first understand the reason for the change. If it is regulatory then the change will most likely have to be included but at the cost of a delay in the project delivery. If it is not regulatory then a dialogue is required with the customer to understand the priority, whether it can be included in the current phase or if it could be delivered in the next phase. The best method is to do the MoSCoW analysis. This will definitely provide the business analyst the information that he or she seeks.

Don’t forget to leave your comments below.

Aruna Parameswaran Mahesh is a technical person with 12+ years of experience who moved into a functional role by choice. Currently working as a business consultant and mentor with an IT organization, Aruna has led the requirements phase of multiple implementation projects across geographies while spending the last 6 years specializing in the life insurance domain in the UK and Asia-Pac regions.