Tag: Best Practices

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.

Three Tips for Solving the Communications Dilemma

Written by Elizabeth Larson on October 4, 2011. Posted in Articles. 2 Comments on Three Tips for Solving the Communications Dilemma

Recently I talked to a colleague with a communications dilemma. She wondered how she should communicate with her various stakeholder groups. Thinking out loud she pondered, “When I’m with business people, I always try to use business language, including their acronyms, which I’ve gone out of my way to learn. But what about when I’m talking to the technical experts? Should I talk techie to them?” She went on to say, “I write a lot of proposals. I have some stakeholders who let me know right away about typos or if my grammar is not exactly right. I have other stakeholders who have told me that my writing style is too formal and that I shouldn’t use such correct grammar. They feel it’s intimidating and unfriendly.”

As BAs and PMs we know we’re supposed to be good communicators, but what exactly does that mean? We are trained to be aware of others’ communication style. We use our intuition, empathy, and awareness of body language to “read” others. But is that enough? And does that apply equally to our written and our verbal communication? What about the language we use? I have always loved the quote from the poet William Butler Yeats, “Think like a wise [person] but communicate in the language of the people.” Does that mean, however, that when we are talking to someone who misuses the language, that we should match our language to theirs? I don’t think so. Matching the communication style does not necessarily mean mimicking their language. However, we do want a communication style that makes our stakeholders comfortable.

How can we solve this communications dilemma? Here are three tips for both written and verbal communications that can help.

Take the time to keep it simple. We are all aware of the wisdom of keeping it simple, but simple doesn’t mean easy. Simple doesn’t mean careless. It is often harder to keep it simple, because keeping it simple requires thought, precision, and a good command of the language. I find that it takes a great deal of thought to write concisely and say everything I want to in language that all stakeholders will understand.
That same principle of simplicity applies when we paraphrase, or restate what was said in different words while keeping the nature of what was said intact. I think paraphrasing is one of the most difficult skills to master. It requires the ability to take in a lot of information, to synthesize it, to concentrate on what is being said, and at the same time to rework the ideas to make them understandable. It’s tough work!
Be correct without being pretentious. When we use incorrect grammar or when we don’t bother to check our work, we run the risk of being judged poorly, of reducing our credibility, and of not being taken seriously. On the other hand, when we use ornate language and complex sentence structure, we run the risk of losing our audience. I remember taking a multiple choice test in high school where the correct answer was “It is I who am going shopping.” Wow. And of course there’s the famous line from Churchill. Apparently his editors rewrote a sentence to make it grammatically correct, and apparently he responded with the famous line, “This is the sort of bloody nonsense up with which I will not put,” pointing out the ridiculous nature of obscure grammatical rules. In a nutshell, I think we should strive for communications that are both intelligent and clear.
Use language that both technical and business people understand. I have found that when I use technical language with business people, they have a harder time understanding me than if I use business language with technical people. Using business language, then, tends to be more easily understood by all stakeholders. As a project manager working on software development projects, I always encouraged the developers to use business terms, even when the subject was technical in nature. For example, instead of saying DB17, I encouraged the team to talk, even among themselves, about the Price Change database.

Another example I use is that when we need to find out about data business rules, we might walk into a requirements workshop and ask about the cardinality and optionality, but we’d probably get some blank stares. However, we can translate those concepts into questions our SMEs can understand and answer. For example, we might ask if end-users can set up customers who don’t have any accounts. Or what information the end-users need to enter before they can leave the web page. I have always believed that translating technical concepts into business English, while annoying to some team members and technical whizzes, has always been worthwhile. It encourages us to focus on the business need rather than the technical solution.

Finally, let’s look at the intent of the communications. If we all understand each other and what we’re trying to say, then I believe we are communicating effectively, even if our grammar isn’t perfect or we don’t use the right words. And I believe that most stakeholders get that and won’t judge us harshly. However, for those stakeholders who want each “i” dotted, let’s proof our work. It will help build our credibility. The key is to know our stakeholders, but that’s a topic for a different day.

Don’t forget to leave your comments below!

Solve it with Science

Written by Neil Karan on September 20, 2011. Posted in Articles.

Remember those days in elementary school science class when the teacher would stand up in front of everyone and ask a question that required solving? The question was always designed to get the neurons in our brains firing, and begin brainstorming solutions to the problem. During those brainstorming sessions we’d eventually develop a problem statement or hypothesis, which was synonymously referred to as a hunch amongst the kids in class. Whether we realized it or not, our hunch or problem statement would become the foundation of our problem-solving process; the postulation as to why we felt the subject matter in question was occurring, and the possible causation.

Eventually we’d start going through the motions of testing our hypothesis; identifying our manipulated and controlled variables in hopes that it would provide us with a responding variable that would confirm our hunch. If at the end of our experiments we found that our theory wasn’t supported, then we’d develop a new hypothesis and start the process again.

So with that said, couldn’t a simplistic view of solving problems the way we used to when we were kids be applied to our problems today? The use of this basic method of theorizing and experimenting can become an intricate tool in solving problems that plague or hinder the success of a project.

This article is designed to remind and re-engage you in a thought process that was taught to us at a young age and that can help you tackle the problems impacting your project today. What this article is not designed to be is an exercise in technical jargon or buzzwords, but one focused more on the utilization of simple logic when trying to figure out the root cause of an issue.

No matter what the issue is, a similar thought process should be running through all our minds when identifying and responding to a problem:

Figure 1

A. Identify the Issues

Begin by understanding what problems have been plaguing the project (e.g., a lack of project charter, poor team member participation, etc.). A suggested approach is to go through the original plan for the project and perform a gap analysis of where things should be versus where they are today. As a member of the team, or as project manager (“PM”), you should have a good idea of what’s been slowing down the project. Consideration should also be given to collaborative discussions with the team that could also bring to surface issues that may not be apparent to all members or the PM but could have a material impact on the success of the project.

Once you’ve gone through and listed potential problems, the next suggested step is to risk rank each issue to determine their importance and resolution priority.

B. Prioritize the Issues

To determine which issues to tackle first, the suggested approach is to risk rank each issue and prioritize each based on complexity and impact. In this context, complexity can be viewed from many perspectives. But to provide simplicity and ease of thought, consider viewing it from a component standpoint (e.g., how many information inputs and outputs are impacted by the problem, how many parties or business units are impacted, etc.). For example, compare the following three issues:

Complexity:

Comparing each issue, it’s easy to identify that issue A is more complex than issue C, involves a greater degree of effort to resolve, and impacts more business units and information outputs than issue C.

Now that we have a basic understanding of complexity, let’s move on to the impact component of the risk ranking exercise.

Impact can be interpreted as the level of damage the issue can cause if it goes unresolved. The damage, for all intents and purposes, is most easily understood when quantified in terms of time required for completion and effort expended; this understanding translates nicely with project timelines and helps provide clarity when the project and identified issues are monetized to the project sponsor. Consider the same issues above, but this time with impact as the risk consideration:

Impact:

With an understanding of complexity and impact, the final step is to map each against a risk grid. The grid visualizes where your issues rank and helps to vet which issues should be tackled first, from highest to lowest risk. A typical grid that could be used is as follows:

Figure 2

Risk Ranking		Complexity
Risk Ranking		Low	Medium	High
Impact	Low	Low	Low	Medium
	Medium	Low	Medium	High
	High	Medium	High	High

Using the grid above, you should now be able to generate a list of issues that are prioritized based on the level of complexity and the overall impact they can have if left unresolved.

C. Figure out the Root Cause of the Problem

Now that you know which issues require immediate attention, the next step is to postulate the cause of the problem, because understanding why the problem is occurring or has occurred will be the only way to develop insight into developing a solution. For example, if the top-ranked risk for your project is that team members no longer attend project meetings, the first step is to develop a hypothesis as to why this may be occurring. The key of the hypothesis is stating the effect and the proposed cause that requires confirmation through experimentation, whether it is confirmed empirically or simply with reasons jotted down on a bar napkin. If, through your hypothesis and experimentation, you determine that no one is attending the meetings (effect) because food isn’t provided to attendees (cause), you can now move towards resolving the issue (i.e., provide food at meetings). The simplicity of the example may seem a bit ridiculous, but you’ll be surprised as to the simple cause of some of the problems impacting your projects.

D. Implement the Solution

The final step when trying to resolve issues is to implement the solution developed during the root cause analysis process. It’s during this time that you’ll be able to tell whether the hypothesized solution will in fact work (i.e., does providing food at meetings actually result in more people attending?). If during this process and the post-implementation of the solution there exists a gap between what is expected versus what actually results, there may be a need to reinitiate the problem-solving process (i.e., repeat step C.)

If the problem is large or complex enough with multiple variables, the above process can become quite extensive but the baseline principles will still hold the same.

To summarize, thoughtful thinking throughout the problem-solving process is essential to the success of resolving issues in a timely and effective manner. It’s important to be cognizant of your actions and activities throughout a project. Emphasizing a greater effort in planning with a preventative mindset in place aims to ensure that problems won’t arise due to a lack of project charter, multiple project sponsors, etc. If, unfortunately, you are experiencing problems with the project, barring any unusual or extreme circumstances, consider the steps above to help devise a simple and methodical strategy for resolving issues threatening your projects completion.

Don’t forget to leave your comments below.

Neil Karan, CFE, CISA is an experienced financial process and IT auditor who provides direction and guidance for audit and project programs. His areas of expertise include business process effectiveness and efficiency programs, operational process design and financial/IT integrity audits.

How To Squash The Template Zombie Problem

Written by Robin Grace on September 6, 2011. Posted in Articles.

Western culture worships the massacre of zombies by the dozen in movies, books, and music. Wherever we encounter zombies, whether it’s in the garden shed, the attic, the mall, or even the local if your name’s Shaun, we are taught to mow them down with whatever’s at hand.

We have only recently discovered that there are different types of zombies, and one type has invaded your office: the template zombie. There isn’t any need to panic but there’s cause for mild alarm and you should kill them. But in the nicest possible way, by feeding them sweeties.

Template zombies are BAs who just fill in the template blanks. When they’re asked to assist on a project, they immediately reach for the templates they’ve been given, fill in all the blanks and then send them on to the developers. And, let’s face it, that’s a lot of documentation to wade through and we all know developers bin the bulk of it, use a small section to write the programs and everyone’s happy. Or are they?

Companies with a poor requirements discovery competency take 39% longer and spend 49% more to deliver their projects. Nearly 80% of their projects are over budget and over time, and a whopping 50% are runaway projects. Runaway projects are those that go 180% over time, 160% over budget and deliver less than 70% of functionality.

You see, grabbing for templates and filling in blanks is akin to BAs reaching for a bag of liquorice allsorts. There’s no control over what’s in the bag, they simply get the whole package whether they like it or not.

In doing so, there’s little, if any, thought given to what the business is actually looking for. The Dryfus model (used in the IIBA Competency Model Version 3.0) for skills acquisition defines a novice as “someone who rigidly adheres to taught rules or plans and is unable to use discretionary judgement.” The template zombie has never been allowed to develop beyond being a novice, no matter how long they have been doing the job, and it’s no wonder their brain dies after a while. That’s a poor approach since the BA has a role to play in achieving a desired business outcome. If it’s properly done, the business gets a working process, be it manual or automated, but if it’s improperly executed the business gets a lame duck.

In fact, the duck can be so lame that the business has late projects, projects that cost significantly more than they were supposed to, and processes, automated or manual, that don’t meet the requirements. More specifically, developers end up with reams of documentation they don’t need that require effort and expense to create, and they ignore most of it. Poor business analysis also negatively impacts stakeholder input and user acceptance.

Bullet to the brain

So now you know how to spot the zombies: they’re the mindless template devotees. What you must now do is rob the zombies of their sustenance and turn them back into effective BAs. How? Steal their liquorice allsorts and give them pick ’n mix. Pick ’n mix allows people to choose precisely what they want; it’s the ultimate in sweet flexibility because you get a bag and then you browse the seemingly endless options, placing the type and number of confectionery delights in it that you want. It gives a much wider selection than liquorice allsorts because the latter’s a predetermined bag of goodies, while the former is an endless sea of choice that lets wave after wave of sweetie, lolly and candy choice wash over you. Again, it’s effective and that’s our watchword in taking down the zombie menace one toe-scraping carcass at a time.

Template zombies like the liquorice allsorts approach because they get the bag, eat the sweets, repeating ad infinitum. But you have to shake them up, make them think. Of course, in doing so, you need to remember that you’re dealing with zombies here and even the most docile template zombie can be dangerous. Don’t give them free rein with the pick ’n mix bag of sweeties or they’ll likely shuffle along the shelves grabbing all their favourite goodies and leaving everything else. You need to point them to the right shelves and only then release them.

Frame the zombie

While it may be ideal to leave BAs to decide what sweets they want from the entire sweet store, only the most senior BAs are capable of doing that within the greater business context, which is the task of what the Dryfus model defines as an expert. Template zombies aren’t the senior BAs. They’re the other BAs. What template zombies need is a framework to guide them through the process.

The business analysis framework must deliver value to the business, otherwise why are we doing the project? And it implies a problem scope. Not necessarily problem in the standard sense—think of it more in the mathematical sense as a problem for which there is a solution. Once we figure out what the solution is, we need to figure out how we are going to deliver it. Think of it as three layers of a pyramid: at the top we ask a) why are we doing this project, followed by b) what do we need to do, and finally c) how do we deliver the solution?

When we ask why we are investigating the business objectives or goals, when we ask what we are eliciting the business requirements, and when we ask how we’re looking into the functional and non-functional requirements.

Another way of looking at it is when we ask why we are seeking the value of the project, when we ask what we are investigating the entities, processes and business rules, and when we ask how we are looking at the required solution functionality. The framework gives us a matrix of objectives on one axis, and tasks or techniques on another, all culminating in outcomes and deliverables. It’s that matrix that arms BAs to choose which techniques are best suited to their projects. All BAs are armed with a bag of sweeties they can dip into, containing practices and disciplines such as planning, business case, business requirements, functional requirements, non-functional requirements, transitional requirements, solution validation, elicitation, and requirements communication. Within each of those portions of the matrix are tools that BAs can use to help them achieve their goal and that’s their pick ’n mix. They’re given the matrix, the framework, but they get to choose within the framework because that’s where they’re the domain experts. For example, they may choose more common tools such as process analysis, ERD, use case and others. But there are several methods of analysis, such as PESTLE, heptalysis (which is not a gum disease), MOST, SWOT, CATWOE (which is not a sad cat), De Bono’s Six Thinking Hats, Five Whys, MoSCoW, and others in their bag of sweets.

Powwow

But what are they looking for in selecting these techniques or sweeties? Some time ago I attended a presentation by Scott Ambler, who is an Agile guru. Often at a conference or industry powwow, there’s a pearl of wisdom that leaps out and sticks in your brain. For me it was, “We need repeatable results, not repeatable processes.” Pick the right tool for the job.

It requires some thought from BAs in the context of the business while considering the numerous techniques available before ensuring a suitable match. Handing BAs a bag of liquorice allsorts in which they’ll find a predetermined collection of techniques that they must follow because “that’s the way we’ve always done it” doesn’t cut it—that is just a repeatable process. You need to appropriately select the techniques that will most effectively deliver against the requirements in the context of the business objectives for repeatable results.

Don’t forget to leave your comments below.

Robin Grace is a Business Analyst Principal Consultant at IndigoCube.